Как проверить сайт на уязвимости с помощью WPScan

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

WPScan предназначен для аудита сайтов на WordPress. Он определяет CMS, ищет установленные плагины и темы, проверяет версии, обнаруживает некоторые конфигурационные недочёты и сопоставляет найденные компоненты с базой известных уязвимостей. Использовать инструмент следует только на собственном сайте или с явного разрешения владельца.

Для разных задач подойдут разные режимы проверки:

Задача	Режим WPScan	Что можно узнать	Важное ограничение
Быстрый обзор	Пассивное сканирование	Версию WordPress, видимые плагины и темы	Часть компонентов может остаться незамеченной
Поиск плагинов	--enumerate vp	Установленные плагины и известные проблемы	Активные запросы создают нагрузку
Проверка тем	--enumerate vt	Названия тем и сведения об их версиях	Версия определяется не всегда точно
Поиск пользователей	--enumerate u	Открытые имена учётных записей	Результат зависит от настроек сайта
Расширенный аудит	Агрессивный режим	Больше признаков и потенциальных точек риска	Требует разрешения и контроля нагрузки

Что именно проверяет WPScan

WPScan анализирует доступные извне признаки сайта: заголовки HTTP, HTML-код, RSS-ленты, имена каталогов, файлы стилей и JavaScript, REST API и стандартные маршруты WordPress. По этим данным программа пытается определить версию ядра, активную тему и набор расширений.

Отдельное направление — поиск уязвимостей в компонентах. При наличии API-токена WPScan сверяет версии WordPress, плагинов и тем с собственной базой данных. В отчёте могут появиться идентификаторы CVE, ссылки на описания проблемы и оценка серьёзности. Это полезнее, чем простой список найденных названий, поскольку позволяет расставить приоритеты.

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

Подготовка к безопасному сканированию

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

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

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

Установка и первый запуск

WPScan написан на Ruby и доступен для Linux, macOS и Windows через подходящую среду Ruby. На Linux обычно достаточно установить пакет Ruby, затем выполнить установку самого инструмента:

gem install wpscan

Проверить доступность программы можно командой:

wpscan --version

Самый осторожный вариант запуска выглядит так:

wpscan --url https://example.ru --plugins-detection passive

Вместо адреса укажите собственный сайт с протоколом HTTPS. Если ресурс использует нестандартный порт, его можно добавить в URL. Для автоматического сопоставления компонентов с базой уязвимостей понадобится API-токен WPScan:

wpscan --url https://example.ru \
  --plugins-detection passive \
  --api-token ВАШ_ТОКЕН

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

Перечисление плагинов, тем и пользователей

Для поиска уязвимых плагинов применяется перечисление vp, а для тем — vt. Комбинированная команда может выглядеть так:

wpscan --url https://example.ru \
  --enumerate vp,vt \
  --plugins-detection passive \
  --api-token ВАШ_ТОКЕН

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

wpscan --url https://example.ru \
  --enumerate vp \
  --plugins-detection aggressive \
  --api-token ВАШ_ТОКЕН

Такой запуск делает больше запросов и требует особой осторожности. Он не должен превращаться в бесконтрольный перебор каталогов на чужой инфраструктуре.

Перечисление пользователей выполняется параметром u:

wpscan --url https://example.ru --enumerate u

Эта функция показывает, какие имена учётных записей могут быть раскрыты через REST API, архивы автора или другие признаки. Само по себе обнаружение имени не является взломом, но облегчает подбор пароля. Поэтому после проверки стоит отключить ненужное раскрытие пользователей и использовать уникальные длинные пароли с многофакторной защитой.

Как читать отчёт сканера

В начале отчёта обычно отображается обнаруженная версия WordPress, URL, серверные заголовки и сведения о включённых функциях. Затем появляются найденные плагины, темы и пользователи. Строки с маркерами вроде [+], [-] или [!] помогают быстро отделить найденные сведения от предупреждений.

Особое внимание уделяйте сообщениям с CVE, ссылками на базу WPScan и рейтингом серьёзности. Уязвимость в старой версии плагина не всегда означает, что сайт непосредственно уязвим: проблема могла быть исправлена разработчиком, но база или определение версии могут быть неточными. Всегда сверяйте результат с официальным журналом изменений и текущей версией расширения.

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

Частые ошибки при проверке

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

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

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

Что делать после сканирования

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

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

После устранения проблем повторите сканирование и сравните отчёты. Дополнительно проверьте права файлов, конфигурацию HTTPS, защиту панели администратора, резервное копирование и журналы входа. Состояние базы WordPress тоже влияет на надёжность сайта; полезные практические сведения о работе с ней собраны в материале про оптимизацию через phpMyAdmin.

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