Безопасность PHP-приложений

MD5 и SHA-1 сделаны быстрыми, поэтому атакующий перебирает миллиарды вариантов в секунду — соль лишь ломает заранее посчитанные rainbow-таблицы, но перебор она не замедляет. password_hash() использует bcrypt или argon2: случайная соль на каждый хеш плюс настраиваемый cost factor делают каждую попытку намеренно дорогой. password_verify() вычитывает алгоритм, соль и cost обратно из сохранённой строки.

Инъекция возникает, когда пользовательский ввод склеивается со строкой SQL и становится синтаксисом, который исполняет парсер. Подготовленное выражение сначала отправляет запрос на сервер — он разбирается и планируется до того, как придёт хоть одно значение, — а связанные параметры едут отдельно, как данные. Поэтому параметр никогда не может стать SQL.

CSRF работает потому, что браузер сам прикладывает вашу сессионную куку к любому запросу на ваш origin, включая форму, отправленную со страницы атакующего, — и кука ничего не доказывает о том, откуда пришёл запрос. Токен, который сервер вложил в вашу страницу, нельзя прочитать со стороннего сайта, поэтому отправить его может только ваша страница. SameSite сужает атаку, но это эшелонированная защита, а не замена.

Закоммиченный секрет остаётся в истории репозитория навсегда — он есть в каждом клоне, форке и логе CI, и удаление строки следующим коммитом его оттуда не убирает. Держите секреты в переменных окружения или в менеджере секретов, коммитьте только .env.example с пустыми значениями, а настоящий .env вносите в gitignore. Утёкший ключ надо ротировать, а не просто удалить.

В куке лежит только идентификатор сессии — непрозрачная случайная строка. Данные из $_SESSION живут на сервере, по умолчанию в файле внутри session.save_path, и ключом служит этот идентификатор. Поэтому идентификатор — предъявительский токен: кто им владеет, тот и есть пользователь, и потому он обязан быть непредсказуемым, ходить по HTTPS и иметь флаг HttpOnly.

XSS — это подконтрольные атакующему данные, отрисованные как разметка или скрипт в браузере другого пользователя. htmlspecialchars() кодирует <, >, & и кавычки, что делает значение безопасным как текст в теле HTML и, с ENT_QUOTES, внутри закавыченного атрибута. Но оно не станет безопасным внутри блока <script>, URL вида javascript: или незакавыченного атрибута — экранирование зависит от контекста.

Валидация решает, приемлемы ли данные для вашей предметной области — email выглядит как email, возраст лежит в 0-150, — и выполняется один раз, на входе. Кодирование решает, как значение безопасно отрисуется в одном конкретном контексте, и выполняется на каждом выводе. XSS останавливает только кодирование: одна и та же сохранённая строка безопасна как текст HTML и опасна внутри блока <script>. Валидация сужает ввод, но не делает его пригодным для печати.

Он считает запросы на одну личность за одно временное окно. Счётчик живёт по ключу из того, что идентифицирует вызывающего — API-ключ, идентификатор пользователя или IP-адрес, если ничего лучше нет, — вместе с окном. Хранится он в общем хранилище вроде Redis, а не в памяти PHP, ведь каждый воркер PHP-FPM обслуживает свой запрос. За лимитом вы отвечаете 429 с заголовком Retry-After.

Атакующий подсовывает идентификатор сессии, который уже знает — через ссылку, поддомен или подставленную куку, — и ждёт, пока жертва войдёт под ним. Этот идентификатор становится аутентифицированным, а держит его атакующий. Лечится это выдачей нового идентификатора в момент смены привилегий: session_regenerate_id(true) сразу после успешного password_verify(), что заодно уничтожает старые данные сессии.

Плейсхолдер — это слот для значения: сервер сначала разбирает запрос, поэтому связанный параметр может быть только данными и никогда — идентификатором или ключевым словом. ORDER BY :col отсортировал бы по константной строке, а не по столбцу. Пропустите ввод через allowlist — массив разрешённых имён столбцов — и вставляйте только то значение, которое из него достали. Направление ASC/DESC тоже идёт через allowlist.

Счётчик — в общем хранилище: Redis с атомарным INCR и сроком жизни, ведь каждый воркер — отдельный процесс. Ключуйте по личности, а не по соединению: идентификатор аккаунта после аутентификации, API-ключ для партнёров, адрес — только как анонимный запасной вариант, чтобы офис за одним NAT не стал единой корзиной. Вход ограничивайте отдельно и заметно жёстче. Скользящее окно не даст залпу удвоиться на границе фиксированного. Отвечайте 429 с Retry-After и осознанно выберите поведение при падении хранилища: fail-open или fail-closed.

Значения связываются: фильтры, список IN (по сгенерированному плейсхолдеру на элемент) и LIMIT. Идентификаторы — нет: столбец сортировки и её направление обязаны приходить из allowlist, а не из запроса. PDO::quote() связывание не заменяет. А ATTR_EMULATE_PREPARES = true означает, что PDO подставляет значения на стороне клиента, и никакого серверного разбора до связывания нет вовсе — выключайте. И пусть покажут EXPLAIN и замер: «ORM был медленным» — это утверждение, а не факт.