Взаимодействие с базами данных
Ээх, сейчас бы в 2017 году о SQL-инъекциях рассказывать
для некоторых это актуально
Предлагаете везде монструозные ORM использовать?

*Не имею ничего против ORM*
Подготовленных выражений будет достаточно
Нет, я в целом о уязвимости. Ей уже так много лет что слабо верится в то что разработчик который хоть чуть-чуть волнуется о безопасности своего приложения не знает о инъекциях.
Если разработчик знает все необходимое, зачем он читает туториалы?
Разработчик — это не только и не столько компания, сколько конкретные студенты в ней работающие
Я о конкретных людях. Вряд ли какая-то организация заставляет кого-то читать хабр по долгу службы (кроме модераторов, конечно).
Читаю всякие рассылки уязвимостей. Один-два раза в месяц приходит что-нибудь из wordpress. У них до сих пор встречаются sql-инъекции. Добро пожаловать в будущее.
Вы не поверите…
Просматривая вопросы от новичков по PHP+MYSQL на RUstackoverflow — можно почти в каждом вопросе увидеть прямые вставки переменных в запрос. Что самое смешное, при этом используется mysqli или PDO (как-будто людям сказали, что расширение mysql небезопасно, но не сказали почему). Так что увы, но тема, похоже, вечная.
как-будто людям сказали, что расширение mysql небезопасно, но не сказали почему

Людям сначала сказали, что оно deprecated, а теперь, что его вообще нет (самостоятельную сборку и прочие бубны опустим для ясности). 98,58551% (субъективно, по свежему опыту) портирования с mysql на mysqli вообще тупо в добавлении одной буквы заключается.

К загрузке файлов: если проверяете тип файла (чаще надо, чем не надо), не доверяйте ни $_FILES['userfile']['type'], ни, тем более, расширению в $_FILES['userfile']['name'], всегда используйте mime_content_type.

Да и это не 100% гарантия того что файл имеет нужный нам тип т.к под капотом используется libmagic, которая проверяет только сигнатуры в хедерах файла.
Тем не менее как первый уровень валидации это хороший совет. И что интересно, в фреймворках(и на других ЯП) зачастую используется именно Content-Type приходящий с формой, а он вообще может быть какой угодно.

Ну да, проверка по сигнатурам. Но в целях безопасности особо проверить больше нечем, если не писать/использовать полноценные анализаторы форматов без использования стандартных библиотек, для выявления явных несоответствий.
в 2018-м вы будете пользоваться PHP 7.2
На этом пункте bitrix-разработчики начали плакать.
они начали плакать на каждом из этих пунктов
Они начали плакать ещё при чтении заголовка.
Они начали плакать когда вышел bitrix.
Полагаю, они начали плакать сразу как родились.
«Но имейте в виду, что json_decode() уязвима для DDoS-атак посредством хеш-коллизий.»
получается, что с json_decode с параметром assoc=true такой проблемы нет, верно?
мне гораздо удобней работать с массивом, чем с объектом
Дело вкуса, и как я помню массивы копируются, а объекты передаются по ссылке.
Поправьте, если я не прав

если только читать из массива то разницы не будет. Т. е. в php копия массива будет только когда потребуется его изменение.

copy-on-write Семантически они копируются всегда, передаются по значению, но физически копирование происходит при первой попытке изменения.

Почему нет, есть. Массив или объект — нет никакой разницы, объекты хранят значения свойств в той же хеш-таблице. А проблема то и кроется в разрешении коллизий hash таблицы. Зная алгоритм хеша можно подобрать ключи так, что все элементы будут хешироваться в одно и тоже значение, а значит попадут в один и тот же список. А так как при вставке проверяется наличие ключа в массиве, то придется пройтись по всем элементам списка сравнивая ключи. Когда мы десериализуем json — вставляем значения в хеш-таблицу одно за одним, и каждое последующее занимает на единицу времени больше, т.е. эдакая арифметическая прогрессия. Зависимость времени вставки от числа элементов получается квадратичной.

Примеры ключей отсюда
Если скормить вашему API огромный JSON вида
{"Rz2VG":1,"Rz34h":2,"Rz35G":3,"RAAcd":4...}

то после десериализации такой объект/массив будет работать в ~500 раз медленнее обычного (такого же размера), т.к. индексация полей/ключей не работает.
Очень содержательная статья, редко столько информации в таком темпе выдают на хабре. Спасибо!
Не знал, что в svg можно засунуть javascript.

Люблю, когда люди поучают использованию TLS не имея такового у себя на сайте.
https://www.phptherightway.com/
Но статья полезная вне сомнения.

phpBB из самописной лапши в версиях 3.0.х в версиях 3.1. и выше обновляется до компонентов Symphony и прочего относительно современного фарша под управлением Composer. Результат- на 3.0 полторы уязвимости, для эксплуатации одной нужно быть админом и включить флеш, вторая позволяет несанкционированно изменить настройки личных сообщений. На 3.1 и выше- куча дырок и багфиксы к багфиксам.
Это я к тому, что не всегда следование моде и работа со сторонними библиотеками оказывается лучше старого, проверенного лапшекода.
echo htmlentities($string); — это безопасный и эффективный способ остановить все XSS-атаки на страницу


Не все. Если, например, на странице «О себе» есть параметр «Мой Сайт», а пользователь контролирует вставляемую ссылку, то нарушителю достаточно указать javascript:alert() для реализации XSS по клику.
Тут нет двойных кавычек, треугольных скобок, так что функция htmlentities() ничего не отрежет.

Итого: санитайзить надо с учетом контекста.
Хотя применение HTTPS на вашем сервере даёт много преимуществ по безопасности и производительности ...

О каких таких преимуществах по производительности идёт речь?
HTTP/2 работает только поверх HTTPS.

Заблуждение в общем случае.

Просто факт. Я прекрасно знаю и про стандарт, и про поддержку в Edge, но всем плевать, пока её нету в хроме с Nginx. А её там принципиально не будет.

В nginx она как раз есть. listen 127.0.0.1 http2; (без ssl) обеспечивает поддержку cleartext HTTP2 (переменная $http2 принимает значение "h2c").

Шифрование с возможностью поиска
Подробнее: Building Searchable Encrypted Databases with PHP and SQL

На мой взгляд очень спорный подход. В начале идет речь, что использовать AES через openssl плохо, т.к. зашифрованный текст всегда одинаков для одинаковых исходных текстов.
Но при этом для поиска нужен хеш (например, HMAC с другим ключом), который точно также будет выдавать одинаковые хеши. А если нужен поиск по подстрокам — хеши нужны для каждой искомой подстроки.
Мне видится костыльным решение с шифрованием и поиском на стороне php, что логичнее пользоваться средствами шифрования, встроенными в БД для реализации поиска. Но в mysql это будет тот же AES с повторами шифротекстов :(

Сколько пытаюсь изучить вопрос с хранением ключей, ни одна статья не раскрывает этот вопрос. Особенно когда БД и php на одном сервере — увел ключи и все костыли с шифрованием в топку. Как защитить 1 ключ, которым зашифрована вся БД?

Как минимум не хранить их на физических дисках этого сервера, получая их извне только в память на минимально необходимое время. Это защитит от атак, связанных с получением read доступа к физическим дискам.

Только полноправные пользователи могут оставлять комментарии.
Войдите, пожалуйста.