Comments 38
*Не имею ничего против ORM*
Просматривая вопросы от новичков по PHP+MYSQL на RUstackoverflow — можно почти в каждом вопросе увидеть прямые вставки переменных в запрос. Что самое смешное, при этом используется mysqli или PDO (как-будто людям сказали, что расширение mysql небезопасно, но не сказали почему). Так что увы, но тема, похоже, вечная.
как-будто людям сказали, что расширение mysql небезопасно, но не сказали почему
Людям сначала сказали, что оно deprecated, а теперь, что его вообще нет (самостоятельную сборку и прочие бубны опустим для ясности). 98,58551% (субъективно, по свежему опыту) портирования с mysql на mysqli вообще тупо в добавлении одной буквы заключается.
К загрузке файлов: если проверяете тип файла (чаще надо, чем не надо), не доверяйте ни $_FILES['userfile']['type'], ни, тем более, расширению в $_FILES['userfile']['name'], всегда используйте mime_content_type.
в 2018-м вы будете пользоваться PHP 7.2
На этом пункте bitrix-разработчики начали плакать.
получается, что с json_decode с параметром assoc=true такой проблемы нет, верно?
мне гораздо удобней работать с массивом, чем с объектом
Поправьте, если я не прав
Почему нет, есть. Массив или объект — нет никакой разницы, объекты хранят значения свойств в той же хеш-таблице. А проблема то и кроется в разрешении коллизий hash таблицы. Зная алгоритм хеша можно подобрать ключи так, что все элементы будут хешироваться в одно и тоже значение, а значит попадут в один и тот же список. А так как при вставке проверяется наличие ключа в массиве, то придется пройтись по всем элементам списка сравнивая ключи. Когда мы десериализуем json — вставляем значения в хеш-таблицу одно за одним, и каждое последующее занимает на единицу времени больше, т.е. эдакая арифметическая прогрессия. Зависимость времени вставки от числа элементов получается квадратичной.
Если скормить вашему API огромный JSON вида
{"Rz2VG":1,"Rz34h":2,"Rz35G":3,"RAAcd":4...}то после десериализации такой объект/массив будет работать в ~500 раз медленнее обычного (такого же размера), т.к. индексация полей/ключей не работает.
Люблю, когда люди поучают использованию TLS не имея такового у себя на сайте.
https://www.phptherightway.com/
Но статья полезная вне сомнения.
echo htmlentities($string); — это безопасный и эффективный способ остановить все XSS-атаки на страницу
Не все. Если, например, на странице «О себе» есть параметр «Мой Сайт», а пользователь контролирует вставляемую ссылку, то нарушителю достаточно указать javascript:alert() для реализации XSS по клику.
Тут нет двойных кавычек, треугольных скобок, так что функция htmlentities() ничего не отрежет.
Итого: санитайзить надо с учетом контекста.
Хотя применение HTTPS на вашем сервере даёт много преимуществ по безопасности и производительности ...
О каких таких преимуществах по производительности идёт речь?
Шифрование с возможностью поиска
Подробнее: Building Searchable Encrypted Databases with PHP and SQL
На мой взгляд очень спорный подход. В начале идет речь, что использовать AES через openssl плохо, т.к. зашифрованный текст всегда одинаков для одинаковых исходных текстов.
Но при этом для поиска нужен хеш (например, HMAC с другим ключом), который точно также будет выдавать одинаковые хеши. А если нужен поиск по подстрокам — хеши нужны для каждой искомой подстроки.
Мне видится костыльным решение с шифрованием и поиском на стороне php, что логичнее пользоваться средствами шифрования, встроенными в БД для реализации поиска. Но в mysql это будет тот же AES с повторами шифротекстов :(
Сколько пытаюсь изучить вопрос с хранением ключей, ни одна статья не раскрывает этот вопрос. Особенно когда БД и php на одном сервере — увел ключи и все костыли с шифрованием в топку. Как защитить 1 ключ, которым зашифрована вся БД?
Руководство по написанию защищённых PHP-приложений в 2018-м