В прошлой статье мы рассказали о Nemesida WAF Free — бесплатном инструменте для защиты сайтов и API от хакерских атак, а в этой решили сделать обзор популярного сканера уязвимостей Wapiti. Сканирование сайта на уязвимости — необходимая мера, которая, вкупе с анализом исходного кода, позволяет оценить уровень его защищенности от угроз компрометации. Выполнить сканирование веб-ресурса можно с помощью специализированно инструментария. Nikto, W3af (написан на Python 2.7, поддержка которого закончилась) или Arachni (с февраля более не поддерживается) — наиболее популярные решения, представленные в бесплатном сегменте. Разумеется, есть и другие, например, Wapiti, на котором мы решили остановимся. Актуальную версию Wapiti можно установить 2 способами: После этого Wapiti будет готов к работе. Для демонстрации работы Wapiti мы будем использовать специально подготовленный стенд sites.vulns.pentestit.ru (внутренний ресурс), содержащий различные уязвимости (Injection, XSS, LFI/RFI) и прочие недостатки веб-приложений.  Информация предоставлена исключительно в ознакомительных целях. Не нарушайте законодательство! Базовая команда для запуска сканера: При этом имеется довольно подробная справка с огромным количеством опций запуска, например: --scope — область применения
Если вместе с URL для сканирования указать параметр scope, то можно регулировать область сканирования сайта, указав как отдельную страницу, так и все страницы, которые получится найти на сайте. -s и -x — параметры добавления или удаления конкретных URL-адресов. Данные параметры полезны, когда необходимо добавить или удалить конкретный URL-адрес в процесса сканирования. --skip — указанный параметр с этим ключом будет сканироваться, но не будет атаковаться. Полезно, если есть какие-то опасные параметры, которые лучше исключить при сканировании. --verify-ssl — включение или отключение проверки сертификата.
Сканер Wapiti модульный. Однако, для запуска конкретных модулей, из числа тех, которые автоматически подключаются во время работы сканера, нужно использовать ключ -m и перечислять нужные через запятую. Если ключ не использовать, то будут по умолчанию работать все модули. В самом простом варианте выглядеть это будет следующим образом: Данный пример использования означает, что мы будем использовать только модули SQL, XSS и XXE при сканировании цели. Помимо этого, можно фильтровать работу модулей в зависимости от нужного метода. Например -m “xss: get, blindsql: post, xxe: post”. В таком случае модуль xss будет применяться к запросам, передаваемым методом GET, а модуль blibdsql — к POST-запросам и т.д. Кстати, если какой-то модуль, который был включен в список, не потребовался во время сканирования или работает очень долго, то нажав комбинацию Ctrl+C можно пропустить использование текущего модуля, выбрав соответствующий пункт в интерактивном меню. Wapiti поддерживает передачу запросов через прокси-сервер с помощью ключа -p и аутентификацию на целевом сайте через параметр -a. Также можно указать тип аутентификации: Basiс, Digest, Kerberos и NTLM. Для последних двух может потребоваться установка дополнительных модулей. Кроме того, можно вставлять в запросы любые заголовки (в том числе произвольный User-Agent) и многое другое. Для использования аутентификации можно использовать инструмент wapiti-getcookie. C его помощью мы формируем cookie, которые Wapiti будет использовать при сканировании. Формирование cookie выполняется с помощью команды: В процессе работы в интерактивном режиме отвечаем на вопросы и указываем необходимую информацию типа: логин, пароль и прочее:  На выходе получаем файл в формате JSON. Другой вариант — добавить всю необходимую информацию через параметр -d: Результат будет аналогичный:  При рассмотрении основного функционала сканера, конечным запросом для проведения тестирования веб-приложения в нашем случае стал: где среди прочих параметров: -f и -o — формат и путь для сохранения отчета; -m — подключение всех модулей — не рекомендуется, т.к. будет сказываться на времени тестирования и размере отчета; --color — подсвечивать найденные уязвимости в зависимости от их критичности по версии самого Wapiti; -c — использование файла с cookie, сгенерированного с помощью wapiti-getcookie;  --scope — выбор цели для атаки. Выбрав вариант folder будет сканироваться и атаковаться каждый URL, начиная с базового. Базовый URL должен иметь косую черту (без имени файла); --flush-session — позволяет проводить повторное сканирование, при котором не будут учитываться предыдущие результаты; -A — собственный User-Agent; -p — адрес прокси-сервера, если необходим. Результат сканирования представлен в виде подробного отчета по всем найденным уязвимостями в формате HTML-страницы, в понятном и удобном для восприятия виде. В отчете будут указаны категории и число найденных уязвимостей, их описание, запросы, команды для curl и советы о том, как их закрыть. Для удобства навигации в названия категорий будет добавляться ссылка, кликнув по которой можно перейти к ней:  Существенный минус отчета — отсутствие как таковой карты веб-приложения, без которой не будет понятно, все ли адреса и параметры были проанализированы. Также есть вероятность ложных срабатываний. В нашем случае в отчете фигурируют «файлы бэкапов» и «потенциально опасные файлы». Их количество не соответствует действительности, так как подобных файлов на сервере не было:  Возможно, некорректно работающие модули исправят со временем. Также недостатком отчета можно назвать отсутствие окраски найденных уязвимостей (в зависимости от их критичности), или хотя бы их разделения по категориям. Единственное, как мы можем косвенно понять о критичности найденной уязвимости — это применять параметр --color при сканировании и тогда найденные уязвимости будут окрашиваться различными цветами:  Но в самом отчете подобная окраска не предусмотрена. Cканер частично справился с поиском SQLi. При поиске SQL-уязвимостей на страницах, где не требуется аутентификация, никаких проблем не возникает:  Не получилось найти уязвимость на страницах, доступных только после аутентификации, даже с использованием валидных cookie, так как скорее всего после успешной аутентификации будет произведен "выход их сессии" и cookie станут недействительными. Если бы функция деавторизации была выполнена в виде отдельного скрипта, отвечающего за обработку этой процедуры, то можно было бы полностью исключить его через параметр -x, и тем самым предотвратить его срабатывание. В противном случае исключить его обработку не получится. Это проблема не конкретного модуля, а инструмента в целом, но из-за этого нюанса не удалось обнаружить несколько инъекций в закрытой области ресурса. С заданной задачей сканер отлично справился и нашел все подготовленные уязвимости:  Сканер нашел все заложенные уязвимости:  В целом, несмотря на ложные срабатывания и пропуски уязвимостей, Wapiti, как бесплатный инструмент, показывает довольно неплохие результаты работы. В любом случае стоит признать, что сканер довольно мощный, гибкий и многофункциональный, а главное — бесплатный, поэтому имеет право на использование, помогая администраторам и разработчикам получать базовую информацию о состоянии защищенности веб-приложения. Оставайтесь здоровыми и защищенными! Практическая информационная безопасность