Уязвимости PHP: виды, примеры и защита сайта

Откуда берутся уязвимости в PHP

Исторически PHP создавался как простой инструмент для динамических страниц, и многие старые приёмы разработки до сих пор кочуют из проекта в проект: склейка SQL-запроса из строк, вывод переменных «как есть», подключение файлов по имени из параметра. Язык позволяет писать быстро, но не заставляет делать это безопасно, поэтому ответственность лежит на разработчике.

Уязвимости обычно попадают в проект тремя путями. Первый — собственный код с ошибками валидации и экранирования. Второй — сторонние компоненты: плагины, темы, модули CMS и пакеты Composer, в которых находят критические дыры. Третий — окружение: устаревшая версия PHP, небезопасные настройки `php.ini`, лишние права у веб-сервера, открытые служебные файлы.

Важно понимать, что уязвимость сама по себе ничего не ломает. Она превращается в инцидент, когда кто-то её находит. А находят их быстро: после публикации исправления для известной дыры (CVE) боты начинают массово проверять сайты уже в течение часов или дней.

SQL-инъекции: самая известная проблема

SQL-инъекция возникает, когда значение от пользователя подставляется прямо в текст запроса. Достаточно передать в параметр `id` не число, а выражение вроде `1 OR 1=1`, и условие выборки перестаёт работать как задумано: вместо одной записи сайт отдаёт всю таблицу. В более опасных сценариях атакующий выгружает хэши паролей, меняет данные или обходит форму входа.

Технически решение известно давно и не требует сложных усилий: подготовленные выражения (prepared statements) в PDO или mysqli. Запрос и данные передаются в СУБД раздельно, поэтому значение никогда не будет воспринято как часть SQL-команды. Экранирование вручную через `addslashes` или «самописные» фильтры ненадёжны и их лучше не использовать.

XSS, include и загрузка файлов

XSS появляется, когда сайт выводит в HTML строку, пришедшую от пользователя: комментарий, имя, параметр поиска. Если в ней есть тег `<script>`, браузер посетителя выполнит чужой код — отправит куки злоумышленнику или подменит форму. Защита: выводить данные через `htmlspecialchars($value, ENT_QUOTES, 'UTF-8')`, использовать шаблонизаторы с автоэкранированием (Twig, Blade) и настраивать заголовок Content-Security-Policy.

Включение файлов — следующая классика. Код вида `include $_GET['page'] . '.php';` позволяет подставить путь вроде `../../config`, а при включённой настройке `allow_url_include` — и вовсе подключить скрипт с чужого сервера. Решение: белый список допустимых страниц и полный отказ от пользовательских путей.

Загрузка файлов опасна тем, что проверка по расширению или заголовку Content-Type легко обходится. Файл `shell.php`, загруженный в публичную папку, превращается в удалённую консоль управления сайтом. Храните загрузки вне корня сайта или запретите выполнение PHP в этих каталогах, переименовывайте файлы и проверяйте реальный тип содержимого.

Отдельно стоит упомянуть сравнение через `==`. В PHP строки вида `0e12345` при нестрогом сравнении могут считаться числом ноль, поэтому два разных хэша иногда оказываются «равными». Для паролей используйте `password_hash()` и `password_verify()`, для остальных сравнений — оператор `===` и функцию `hash_equals()`.

Как выглядит взлом на практике

Понять логику атаки полезно, чтобы расставить приоритеты в защите. Чаще всего это не «ручной хакер», а автоматизированный сценарий: бот находит сайт с известной уязвимостью, эксплуатирует её, оставляет доступ на будущее и затем использует ресурсы сайта для своих целей. Для владельца всё это остаётся незаметным неделями, пока не придёт жалоба от хостера или не просядет трафик.

Устаревший PHP и громкие CVE

Отдельная категория риска — версия самого интерпретатора. Ветки PHP живут ограниченное время: сначала активная поддержка с исправлением ошибок, затем период только security-патчей, после чего поддержка прекращается. Например, PHP 7.4 перестал получать исправления в ноябре 2022 года, а PHP 5.6 — ещё в конце 2018-го. Сайты, которые продолжают на них работать, остаются с известными дырами без шансов на заплатку. Актуальные сроки поддержки смотрите на официальном сайте php.net.

Хороший пример того, как быстро развивается ситуация, — уязвимость CVE-2024-4577 в PHP-CGI на Windows (оценка CVSS 9.8). Она позволяла через специально сформированный запрос передавать аргументы интерпретатору и выполнять произвольный код. Исправления вышли в версиях 8.1.29, 8.2.20 и 8.3.8, а массовое сканирование сетей началось почти сразу после публикации деталей. Похожая история была с пакетом PHPUnit (CVE-2017-9841): забытая в рабочем окружении папка vendor открывала удалённое выполнение кода.

Мораль простая: обновления — это не опция «по возможности», а часть эксплуатации сайта. Если миграция на новую версию PHP затруднена из-за старого кода, закладывайте её в план работ, а на переходный период ограничивайте доступ к серверу и включайте дополнительную защиту на уровне веб-сервера.

Настройки php.ini, которые стоит проверить

Даже безупречный код выигрывает от правильной конфигурации. Часть настроек сразу закрывает целые классы атак или сильно усложняет их: запрет подключения удалённых файлов, ограничение каталогов, доступных скрипту, защита сессионных cookie. Ниже собран короткий чек-лист директив, которые стоит сверить на рабочем сервере. Значения подбирайте под ваш проект и проверяйте на тестовой копии, чтобы ничего не сломать.