Уязвимости Битрикс и PHP: как найти и закрыть дыры

Почему сайты на Битрикс оказываются в зоне риска

Битрикс — одна из самых популярных CMS в Рунете. Для злоумышленника это удобная мишень: структура каталогов известна (/bitrix/, /upload/, /local/), версия платформы нередко определяется по открытым признакам, а уязвимость, найденная в одном продукте, подходит сразу для тысяч сайтов. Поэтому атаки чаще всего автоматические: боты перебирают адреса и пробуют готовые эксплойты, не интересуясь, кому принадлежит сайт.

Вторая причина — «наследие» проекта. Интернет-магазин на Битрикс живёт годами, над ним работают разные подрядчики, в код добавляются самописные компоненты, подключаются сторонние решения из маркетплейса. Каждый такой элемент расширяет поверхность атаки. Если ядро не обновлялось, а на сервере работает версия PHP, снятая с поддержки, то известные дыры остаются открытыми, и автоматический сканер их находит быстро.

Третья причина — человеческий фактор: простые пароли администраторов, общий доступ по FTP, лишние учётные записи бывших сотрудников и подрядчиков, права 777 на каталоги «чтобы заработало».

Какие классы уязвимостей встречаются чаще всего

Уязвимости на сайтах с Битрикс условно делятся на три группы. Первая — дыры в самой платформе и штатных модулях. Разработчик исправляет их в обновлениях, а в разные годы в модулях находили проблемы разной степени критичности, вплоть до удалённого выполнения кода. Если обновления не устанавливаются, сайт остаётся уязвимым к уже опубликованным способам атаки.

Вторая группа — ошибки в самописном коде и сторонних решениях. Здесь встречаются почти все классические PHP-уязвимости: параметры запроса подставляются в SQL без экранирования, вывод пользовательских данных не фильтруется, загружаемые файлы не проверяются, а пути для подключения файлов собираются из входных данных.

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

Как распознать, что сайт уже взломан

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

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

С чего начинать защиту

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

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

Что делать, если взлом уже произошёл

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

Дальше работа идёт в таком порядке: закрыть доступ (сменить пароли панели, FTP/SSH и базы данных, перевыпустить ключи), найти и удалить веб-шеллы и изменённые файлы, сравнив их с чистым дистрибутивом платформы, проверить базу данных на внедрённые скрипты и устранить причину — обновить платформу, PHP и уязвимый компонент. После этого отправьте сайт на перепроверку в Яндекс Вебмастере и Google Search Console, чтобы предупреждения в поиске были сняты.