Дыра в PHP: как проверить сайт и закрыть уязвимость
Уязвимость в PHP может дать злоумышленнику выполнить код на сервере. Обновите версию, проверьте файлы и логи, закройте лишний доступ.
Дыра в PHP: что это значит для вашего сайта и что делать сразу
«Дыра в PHP» — это уязвимость в самом интерпретаторе, его расширениях или в коде на PHP, через которую посторонний может прочитать данные, подменить файлы или выполнить свои команды на сервере. Закрывается она обновлением версии, правильной настройкой и проверкой сайта на следы взлома.
Новости об очередной критической уязвимости в PHP выходят регулярно. Для владельца сайта они означают одно: у автоматических сканеров есть новая цель. Боты проверяют десятки тысяч адресов в сутки, и ваш сайт попадает в список просто потому, что отвечает на запросы. Разберём, где обычно возникают такие дыры, как оценить собственный риск, что делать в первые часы и как настроить сервер, чтобы следующая уязвимость не стала катастрофой.
Где на самом деле находится «дыра»
Фраза «дыра в PHP» объединяет три разные ситуации, и действия в каждой отличаются.
Первая — уязвимость в ядре языка или его модулях. Это ошибка в самом интерпретаторе, например в обработке параметров запуска, в разборе данных или в работе с памятью. Исправляется только выходом новой версии PHP, и от автора сайта здесь зависит лишь скорость установки обновления.
Вторая — уязвимость в связке PHP с веб-сервером. Так бывает, когда PHP работает через CGI, FPM или иной интерфейс, а Apache или nginx передают ему данные в неожиданном виде. Здесь помогают и патчи, и правильная конфигурация, и отключение ненужных режимов.
Третья — уязвимость в коде, написанном на PHP. Это плагины, темы, самописные модули и устаревшие версии CMS. Формально сам язык ни при чём, но в новостях и на форумах такую проблему тоже называют «дырой в PHP». На практике именно этот вариант встречается чаще всего: большинство взломов происходит через неактуальные плагины, а не через ядро языка.
Как выглядит критическая уязвимость на реальном случае
Внедрение аргументов в PHP-CGI: запрос с особыми символами позволял запустить код на сервере.
Выпуски, в которых проблему закрыли. Более старые ветки поддержки уже не получали.
Под удар попадали конфигурации с определённой кодовой страницей. Это показывает, что риск зависит от настроек.
Почему это касается даже небольших сайтов
Распространённое заблуждение: «мой сайт слишком маленький, он никому не нужен». Злоумышленнику ваш сайт нужен не из-за содержания, а из-за ресурсов. Через взломанный хостинг рассылают спам, размещают страницы с мошенническими предложениями, майнят криптовалюту и используют сервер как промежуточный узел для атак на других. Поэтому автоматические сканеры перебирают адреса подряд и бьют по всем, где находят подходящую версию.
Есть и более тревожные случаи. В марте 2021 года в официальный репозиторий исходного кода PHP были внесены вредоносные коммиты, замаскированные под обычные правки. Их быстро обнаружили и откатили, а в выпущенные версии они не попали. Но история показала, что угрозы возможны не только в коде сайта, но и в цепочке поставки самого языка. Отсюда практический вывод: устанавливайте PHP из официальных источников и проверенных репозиториев дистрибутива, а не из случайных сборок.
Для бизнеса последствия не ограничиваются техникой. Если сайт помечен как опасный, Яндекс Вебмастер и Google Search Console покажут уведомление в разделах безопасности, а в браузерах у посетителей появится предупреждение. Продажи и заявки при этом падают сразу, а восстановление позиций занимает недели.
| Тип уязвимости | Что получает атакующий | Основная защита |
|---|---|---|
| Удалённое выполнение кода (RCE) | Полный контроль над сайтом и часто над учётной записью на хостинге | Быстрое обновление PHP и ограничение режимов запуска |
| Внедрение файлов (LFI/RFI) | Чтение конфигов и запуск чужих скриптов | Проверка путей, отключение allow_url_include |
| SQL-инъекция | Доступ к базе данных, пользователям и заказам | Подготовленные запросы и ограничение прав пользователя БД |
| Небезопасная загрузка файлов | Возможность залить веб-шелл под видом картинки | Проверка типа файла и запрет исполнения скриптов в папке загрузок |
| Устаревшая ветка PHP | Известные дыры, которые уже никто не исправит | Переход на поддерживаемую версию |
Как оценить собственный риск за 10 минут
Чтобы понять, насколько вы уязвимы, нужны три факта: какая версия PHP работает, каким способом он подключён к веб-серверу и как давно обновлялись CMS с плагинами.
Версию узнайте командой php -v в консоли или в разделе настроек PHP в панели хостинга. Не путайте версию в командной строке с версией, которую использует сайт: на одном сервере их может быть несколько. Надёжнее создать временный файл с вызовом phpinfo, открыть его и сразу удалить. Способ подключения (mod_php, FPM, CGI) указан в строке Server API.
Далее сверьте ветку с таблицей поддерживаемых версий на сайте php.net. Если ветка уже не получает даже исправлений безопасности, считайте её уязвимой, даже если конкретного бюллетеня пока нет. И наконец, откройте админку CMS и посмотрите, сколько плагинов и тем ждут обновления. Каждое неустановленное обновление — потенциальная точка входа.
Что делать в первые часы после новости об уязвимости
- 01
Определите версию PHP и способ его запуска. Сравните с описанием уязвимости в официальном бюллетене: часто риск есть только при определённой конфигурации.
- 02
Сделайте полную резервную копию файлов и базы данных. Храните её вне рабочего сервера, чтобы атака не затронула и копию.
- 03
Установите исправленную версию PHP или попросите хостинг-провайдера сделать это. Если патча ещё нет, временно примените рекомендованные меры: отключите уязвимый режим или закройте доступ на уровне веб-сервера.
- 04
Обновите CMS, плагины и темы. Удалите всё, чем не пользуетесь: неактивный плагин с дырой остаётся рабочей точкой входа.
- 05
Проверьте файлы, изменённые за последние дни, и журналы доступа на подозрительные запросы. Найдите неизвестные PHP-файлы в папках загрузок и кэша.
- 06
Смените пароли от хостинга, FTP/SSH, панели управления, CMS и базы данных, а также ключи в конфигурации. Делайте это после обновления, иначе новые пароли могут снова попасть к злоумышленнику.
Как искать следы взлома без специальных инструментов
Самый простой способ — найти файлы, которые менялись недавно. В консоли поиск PHP-файлов, изменённых за последние три дня, выполняется командой find с параметрами -name и -mtime. Если вы ничего не обновляли, а список длинный, это повод для тревоги.
Второй шаг — журналы веб-сервера. Ищите запросы к необычным адресам, длинные строки с кодированными символами в параметрах и обращения к файлам, которых нет в структуре сайта. Третий — задачи по расписанию (cron) и список пользователей: злоумышленники любят оставлять «спящие» точки возврата.
Параллельно посмотрите на внешние сигналы. Яндекс Метрика и Google Analytics покажут резкие всплески трафика из странных источников или на незнакомые страницы. Яндекс Вебмастер и Google Search Console могут сообщить о проблемах безопасности и показать в индексе страницы, которых вы не создавали.
Если совпало два пункта и больше, действуйте как при взломе
- 01В индексе Яндекса или Google появились страницы с чужим текстом, казино, лекарствами или товарами
- 02Посетители с мобильных устройств или из поиска попадают на сторонние сайты
- 03В папках загрузок или кэша лежат файлы .php с непонятными названиями
- 04Нагрузка на сервер выросла без роста посещаемости, хостинг шлёт предупреждения
- 05В админке появились незнакомые пользователи или неизвестные плагины
- 06Вебмастер или Search Console показывают уведомление о проблемах безопасности
Типичные ошибки при реакции на уязвимость
Как делать не стоит
- Сразу менять пароли, не обновив PHP и CMS: злоумышленник по-прежнему имеет доступ и получит новые данные
- Удалять один найденный вредоносный файл и считать проблему решённой
- Восстанавливать сайт из копии, не выяснив, когда произошёл взлом: копия может быть уже заражена
- Оставлять файл phpinfo на сервере после проверки версии
- Откладывать обновление «до выходных» при критическом бюллетене
Как правильно
- 01
Закройте уязвимость, затем ищите последствия, а уже потом меняйте доступы
- 02
Ищите не один файл, а закономерность: время изменения, одинаковые фрагменты кода, общий владелец
- 03
Берите копию, сделанную до первых признаков взлома, и сразу обновляйте её
- 04
Удаляйте все диагностические файлы сразу после использования
- 05
Для критических уязвимостей планируйте обновление в течение суток
Настройки, которые снижают ущерб от будущих дыр
Идеальной защиты от неизвестных уязвимостей не существует, но можно сделать так, чтобы взлом не перерос в катастрофу. Принцип простой: даже если злоумышленник нашёл способ выполнить код, он должен упереться в ограничения.
Первое — минимальные права. Пользователь, от имени которого работает PHP, не должен иметь права записи во все папки сайта. Запись нужна только в каталоги загрузок и кэша, и в них необходимо запретить исполнение скриптов на уровне веб-сервера.
Второе — отключение лишних возможностей в php.ini. Опасные функции запуска системных команд, которые сайт не использует, стоит добавить в disable_functions. Вывод ошибок на экран на рабочем сайте лучше выключить: сообщения раскрывают пути и структуру проекта. Скрытие версии PHP в заголовках ответа не защита само по себе, но убирает лёгкую подсказку для сканеров.
Третье — отдельные учётные записи и базы данных для разных сайтов. Если на одном аккаунте живёт десяток проектов, взлом одного означает взлом всех.
Три строки конфигурации, которые уменьшают поверхность атаки
expose_php = On display_errors = On allow_url_include = On
Версия PHP видна в заголовках, ошибки показывают пути к файлам, а подключение удалённого кода разрешено.
expose_php = Off display_errors = Off allow_url_include = Off
Лишние сведения скрыты, ошибки уходят в журнал, а удалённое подключение кода запрещено.
Итоги: как пережить «дыру в PHP» без потерь
- 01
Узнайте версию PHP и способ его запуска, сверьте с официальными бюллетенями
- 02
Сначала обновите PHP, CMS и плагины, затем ищите следы взлома и только потом меняйте пароли
- 03
Держите резервные копии вне рабочего сервера и проверяйте, что из них можно восстановиться
- 04
Ограничьте права PHP, запретите исполнение скриптов в папках загрузок, отключите лишние функции
- 05
Следите за уведомлениями в Яндекс Вебмастере и Google Search Console и за аномалиями в Яндекс Метрике и Google Analytics
Безопасность сайта — это не разовая акция, а регулярная рутина: проверить версию, обновить компоненты, посмотреть журналы. Чем раньше вы встроите её в рабочий процесс, тем спокойнее встретите следующую новость об уязвимости. Если нет времени или опыта разбираться самостоятельно, проще доверить аудит специалисту, чем восстанавливать репутацию сайта после взлома.
Часто задаваемые вопросы
Выполните на сервере команду php -v или откройте в панели хостинга раздел с настройками PHP. Затем сравните номер версии с бюллетенями на официальном сайте php.net. Если ветка снята с поддержки, она уязвима по определению: исправления для неё больше не выходят.
Нет. Обновление закрывает известную дыру, но не удаляет то, что уже успели загрузить. Нужно проверить изменённые файлы, учётные записи, задачи cron и сменить пароли и ключи.
Да. Взломанный сайт часто раздаёт спам-страницы и вредоносные редиректы. Яндекс Вебмастер и Google Search Console пометят его как небезопасный, а в выдаче появится предупреждение и просядет трафик.
Напишите в поддержку и уточните, какая версия работает и когда выйдет патч. Если сроки не устраивают, переключите версию в панели управления на поддерживаемую либо смените тариф на тот, где это доступно.
Версию PHP и обновления CMS проверяйте минимум раз в месяц. Критические бюллетени безопасности читайте сразу после выхода. Резервные копии делайте автоматически, а восстановление пробуйте хотя бы раз в квартал.
Проверим ваш сайт на уязвимости PHP до того, как её найдут боты
Проанализируем версию PHP, настройки сервера и файлы, затем пришлём список конкретных исправлений.
Спасибо за заявку!
Мы свяжемся с вами в ближайшее время.
Более 300 сайтов проверено на уязвимости
