Уязвимости Drupal и PHP: как защитить сайт от взлома

Почему уязвимости Drupal так часто связаны с PHP

Drupal — одна из самых заметных CMS для крупных проектов: порталы, медиа, госсайты, университеты, корпоративные системы. Такая популярность делает платформу привлекательной целью. Злоумышленникам выгодно искать одну брешь, которая работает на тысячах сайтов сразу.

При этом сам Drupal считается достаточно зрелым с точки зрения безопасности: у проекта есть собственная команда безопасности, регламент публикации advisories и оценка рисков по шкале от «Less critical» до «Highly critical». Но язык, на котором написана платформа, накладывает свои особенности. PHP динамически типизирован, умеет превращать строки в вызовы функций, десериализовать объекты из текста и подключать файлы по пути, который может прийти от пользователя. Любая из этих возможностей при недостаточной проверке данных превращается в точку входа для атаки.

Отдельная история — модули сообщества. Ядро проходит строгий ревью, а вот contrib-модули пишут разные авторы с разным уровнем внимания к безопасности. Статистика advisories показывает, что значительная часть бюллетеней касается именно дополнительных модулей, а не ядра.

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

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

Версии Drupal и PHP: почему устаревание опасно

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

Связка Drupal и PHP работает в обе стороны. Новые версии Drupal требуют современный PHP: для Drupal 10 нужен PHP 8.1 или выше, для Drupal 11 — PHP 8.3. С другой стороны, переход на свежий PHP без обновления Drupal может сломать старые модули. Поэтому планировать обновления нужно вместе, а не по отдельности.

Статус поддержки веток PHP удобно проверять на официальной странице supported versions. На момент написания статьи ветка 8.1 получает только исправления безопасности до конца 2025 года, а 8.2 и 8.3 поддерживаются дольше. Проверяйте актуальные даты перед планированием.

Главное в этом процессе — скорость и воспроизводимость. Если обновление требует нескольких дней согласований и ручной подготовки окружения, вы всегда будете отставать от атакующих. Поэтому лучше заранее настроить конвейер: код в репозитории, зависимости под управлением Composer, автоматическая сборка и тесты, быстрый откат.

Полезно подписаться на рассылку security-анонсов Drupal и настроить уведомления Update Status на рабочую почту команды. Для проверки зависимостей на известные уязвимости используйте composer audit: команда сверяется с базой advisories и показывает проблемные пакеты прямо в терминале или в CI.

Настройки сервера, которые закрывают последствия уязвимости

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

В каталоге загруженных файлов запретите выполнение скриптов. Для nginx это правило, которое отдаёт отказ на любые запросы к файлам с расширением php внутри sites/*/files. Для Apache то же достигается через .htaccess, который Drupal создаёт автоматически, но на нестандартных конфигурациях его часто теряют при переносе.

Файл settings.php после установки стоит сделать доступным только для чтения, а в самой конфигурации задать trusted_host_patterns: это защищает от подмены заголовка Host. В php.ini отключите display_errors и expose_php, ограничьте опасные функции через disable_functions там, где это не мешает работе сайта, и задайте open_basedir, чтобы скрипт не мог читать произвольные каталоги сервера.

Отдельно упомяну уязвимости самого PHP. Например, CVE-2024-4577 в PHP-CGI на Windows позволяла внедрять аргументы командной строки. Она не относится к Drupal напрямую, но показывает, что окружение влияет на безопасность не меньше, чем CMS. Поэтому регулярно обновляйте и интерпретатор, и пакеты операционной системы.