Уязвимость PHP RCE: как работает и как защититься

Что такое RCE простыми словами

Представьте, что у вашего сайта есть форма, где пользователь вводит адрес для проверки доступности. Скрипт на PHP берёт введённую строку и передаёт её в командную оболочку сервера. Если разработчик не проверил ввод, то вместо адреса можно подставить собственную команду, и сервер её выполнит. Это и есть удалённое выполнение кода: данные превратились в инструкции.

Код при этом исполняется с правами пользователя, от имени которого работает веб-сервер или PHP-FPM (часто это www-data или apache). Кажется, что права ограничены, но их хватает, чтобы прочитать конфигурационные файлы с паролями от базы данных, изменить файлы сайта, загрузить веб-шелл и использовать сервер как плацдарм для дальнейших атак.

RCE бывает двух видов. В первом случае ошибка находится в самом интерпретаторе или в связке PHP с веб-сервером. Во втором ошибка допущена в прикладном коде: в плагине, теме, самописном скрипте или сторонней библиотеке. Второй вид встречается намного чаще.

Почему именно PHP так часто попадает под удар

PHP работает на огромной доле сайтов в интернете, в том числе на WordPress, Joomla, Drupal, Bitrix, Laravel и Symfony. Большая популярность делает язык привлекательной мишенью: достаточно найти одну ошибку, чтобы получить тысячи потенциальных жертв. Автоматические сканеры проверяют новые уязвимости практически сразу после публикации CVE.

Есть и причины в самом языке. Исторически PHP предоставлял много удобных, но потенциально опасных возможностей: динамическое подключение файлов, выполнение строки как кода, десериализация объектов, прямой вызов команд оболочки. Всё это легко использовать неправильно. Добавьте к этому множество устаревших версий на хостингах и неподдерживаемые плагины, и получите благодатную почву для атак.

Известные случаи: чему они учат

История PHP знает немало громких RCE-уязвимостей. Их полезно изучить не ради любопытства: они показывают, что именно ломается чаще всего и как быстро после публикации CVE начинаются массовые сканирования.

В таблице ниже собраны несколько показательных примеров из разных категорий: ошибки интерпретатора, забытые инструменты разработки, уязвимости в CMS и фреймворках. Проверьте свои версии по этому списку, а затем сверяйтесь с официальными бюллетенями безопасности PHP и вашего фреймворка.

Какие выводы можно сделать

Во-первых, уязвимости живут годами. CVE-2024-4577 по сути стала обходом защиты, созданной ещё в 2012 году. Во-вторых, самые простые ошибки, вроде забытого тестового файла или включённой отладки, дают тот же результат, что и сложные цепочки эксплуатации. В-третьих, время между публикацией уязвимости и началом массовых атак измеряется днями, поэтому откладывать обновления рискованно.

Теперь перейдём от общей картины к конкретному коду. Посмотрим, какие шаблоны в PHP чаще всего приводят к RCE и чем их заменить.

Настройка окружения: второй рубеж обороны

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

В PHP для этого есть несколько директив: disable_functions отключает опасные функции, open_basedir ограничивает каталоги, к которым имеет доступ скрипт, allow_url_include и allow_url_fopen управляют работой с удалёнными адресами, display_errors и expose_php скрывают лишнюю информацию. На уровне веб-сервера важно запретить исполнение PHP в каталогах загрузок и закрыть доступ к служебным каталогам и файлам вроде vendor, .git и .env.

Настройки — не панацея

Важно понимать ограничения. Директива disable_functions не защищает от выполнения произвольного PHP-кода, она лишь затрудняет запуск системных команд, и существуют способы её обхода. Поэтому её нужно сочетать с обновлениями, исправлением кода и минимальными правами для пользователя, от имени которого работает PHP.

Отдельное внимание стоит уделить изоляции. Если на одном сервере живёт несколько сайтов, каждому нужен свой пользователь и свой пул PHP-FPM, чтобы взлом одного проекта не открывал доступ ко всем остальным. В контейнерах стоит запускать процесс не от root и делать файловую систему доступной только для чтения там, где это возможно.

Мониторинг: как заметить проблему вовремя

Полностью исключить взлом невозможно, поэтому важно быстро его обнаружить. Настройте журналы веб-сервера и PHP, следите за изменениями файлов с помощью контроля целостности и регулярно сканируйте сайт антивирусом для серверов.

Используйте и инструменты поисковых систем. Яндекс Вебмастер и Google Search Console сообщают о проблемах безопасности, зараженном контенте и подозрительных страницах. Эти уведомления стоит включить сразу, а не искать их постфактум, когда трафик уже упал. Если подозрения подтвердились, не ограничивайтесь удалением найденного шелла: найдите точку входа, закройте её, смените все пароли и ключи и проверьте сервер на наличие других закладок.