Проверка сайта на уязвимости CMS и плагинов

Зачем проверять сайт на уязвимости CMS и плагинов

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

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

Что проверяем

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

Почему подробности показываем только владельцу сайта

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

• Без подтверждения — сводка: какой движок найден, сколько компонентов уязвимы и сколько устарели. Этого достаточно, чтобы понять, есть ли проблема.
• После подтверждения владения — названия компонентов, найденные версии, актуальные версии и описания уязвимостей. Это нужно, чтобы исправить проблему.

Подтверждение устроено так же, как в Яндекс Вебмастере. Есть два способа:

1. Мета-тег. Мы выдаём тег вида meta name="..." content="код". Добавьте его в раздел head главной страницы — в WordPress это можно сделать в теме или в плагине SEO, в конструкторах — в настройках кода страницы.
2. Файл. Создайте в корне сайта файл levitsky-verification.txt с выданным кодом, чтобы он открывался по адресу ваш-сайт/levitsky-verification.txt.
3. Запустите проверку снова — после подтверждения откроется полный отчёт.

Как исправить найденное самостоятельно

1. Сделайте резервную копию файлов и базы данных. Обновление старого сайта может что-то сломать, и откат должен быть под рукой.
2. Обновите уязвимые компоненты первыми. Уязвимость с опубликованным способом атаки опаснее, чем просто старая версия.
3. Удалите то, чем не пользуетесь. Отключённый плагин всё равно лежит на сервере, и его файлы доступны снаружи. Неиспользуемые плагины и темы удалите полностью.
4. Замените заброшенные плагины. Если плагин давно не обновляется автором, новой версии может не быть вовсе. Ищите замену с активной поддержкой.
5. Обновите ядро. Для WordPress включите автоматические обновления безопасности. Для 1С-Битрикс обновления устанавливаются через «Обновление платформы» при действующей лицензии.
6. Обновите JS-библиотеки. Старый jQuery часто подключён темой или плагином, и обновлять его нужно вместе с ними, проверяя, что ничего не сломалось.

Если сайт долго не обновлялся, уязвимость могли уже использовать. После обновления запустите проверку сайта на взлом и проверку SSL и защитных заголовков. Политика безопасности контента ограничивает ущерб от внедрённых скриптов — её можно собрать в генераторе CSP.

Как часто проверять и как не отставать от обновлений

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

• Включите автообновления там, где это безопасно. Для ядра WordPress обновления безопасности можно ставить автоматически. Плагины, от которых зависит оплата, формы или каталог, лучше обновлять вручную после проверки на копии сайта.
• Держите список установленного. Короткая таблица «плагин — зачем нужен — кто поставил» помогает быстро решать, что обновить, а что удалить.
• Не отключайте обновления навсегда. Если подрядчик отключил их, «чтобы ничего не сломалось», значит, у сайта нет процесса обновления, и риск со временем только растёт.
• Следите за доступом. Уязвимый плагин опаснее, если у сайта много администраторов со слабыми паролями. Удалите лишние учётные записи и включите двухфакторный вход, если движок это позволяет.

Ограничения проверки

• Проверка пассивная. Мы смотрим только публичные страницы и файлы, которые сайт отдаёт любому посетителю. Никаких попыток эксплуатировать уязвимости, подбирать пароли или сканировать порты.
• Видно не всё. Если плагин не оставляет следов на публичных страницах или версии скрыты, мы его не найдём. Отсутствие находок не означает, что сайт безопасен.
• Версия может определиться неточно. Иногда номер версии в файлах не совпадает с фактически установленной. Перед обновлением сверьтесь со списком плагинов в админке.
• Глубина зависит от движка. Подробнее всего проверяется WordPress, для которого есть открытый каталог плагинов и официальный статус версий. Для Joomla и Drupal сверяем с базой уязвимостей версию ядра, если сайт её показывает. Для 1С-Битрикс, OpenCart и MODX определяем движок и JS-библиотеки: версии модулей эти движки снаружи не раскрывают.

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