В данной статье я расскажу об инструментарии для тестирования безопасности веб-приложений. Основные этапы и чек-лист работ представлены в предыдущей статье.

Большинство утилит содержится в популярных дистрибутивах тестирования на проникновение: Kali Linux, BlackArch, BackBox Linux. Для тех, у кого нет возможности по тем или иным причинам использовать эти дистрибутивы, я публикую ссылки на github/страницы утилит.

Основные этапы

Для полноты тестирования необходимо стараться следовать нижеприведенным рекомендациям, кастомизируя те или иные этапы в зависимости от веб-приложения. Далее я опишу этапы и утилиты, которые подходят к каждому из них.

Разведка

Сканирование портов. На этом этапе поможет нестареющая классика — nmap. Для тех, кто столкнулся с этой утилитой впервые, необходимо учесть, что по умолчанию nmap сканирует ~1000 портов (первые и популярные выше), а также не сканирует UDP — имейте это в виду.

Сканирование поддоменов. На этом этапе пригодится работа с утилитой dig и понимание AXFR запросов. Также пригодится утилита subbrute.

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

Поиск скрытого контента (директорий, файлов, информации). На этом этапе пригодятся утилиты dirb, dirsearch, можно воспользоваться инструментами Foca (устарел) и maltego (необходима регистрация, есть платная версия).

Определение платформы и веб-окружения. Здесь необходимо воспользоваться аддоном к браузеру wappalyzer или утилитой whatweb.

Определение форм ввода. На этом этапе можно ограничится визуальным осмотром форм на страницах, выявленных в результате поиска скрытого контента.

Отдельно я бы хотел упомянуть «комбайны» для сбора информации: theharvester и recon-ng — с помощью этих инструментов можно получить довольно много информации — от выявления учетных записей и поддоменов до поиска критичной информации на сайте.

Контроль доступа

На данном этапе требуется как инструментальная, так и ручная проверка требований парольной политики.

Для проверки необходимо провести атаку по словарю, например с помощью hydra или patator, используя заведомо известные учетные данные: таким образом можно выявить защиту от такого рода атак (или ее отсутствие).

Определение требований парольной политики. Здесь ручная проверка логики требований политики. Использование только цифр (например как пин-кода) без защиты от брута — очень плохая идея.

Тестирование восстановления учетной записи. На данном этапе приходится наличие нескольких ссылок или триггеров для сброса пароля (желательно от разных учетных записей). Здесь необходимо будет выявить и определить хеш (частое явление), например с помощью hashID. Далее необходимо произвести сравнение тригеров сброса (например ссылок) с помощью утилит сравнения (например comparer в burp suite).

Тестирование функций сохранения сессии. Тестирование функций идентификации учетной записи. Проверка полномочий и прав доступа. Исследования сессии (время жизни, сессионный токены, признаки, попытки одновременной работы и т.д.) Проверка CSRF. Для этих задач хорошо подойдет mantra — есть версия как в виде firefox, так и chrome сборки.

Фаззинг параметров

Тестирование веб-приложения может быть выполнено как в инструментальном режиме (w3af, vega, arachni, sqlmap, Acunetix, Netsparker и.д.), так и полу-инструментальном — Burp Suite, OWASP ZAP и д.р.

С помощью этих инструментов, как автоматическом, так и в ручном (наиболее точном) режиме можно выявлять следующие уязвимости: инъекции (SQL, SOAP, LDAP, XPATH и т.д.), XSS-уязвимости, редиректы и переадресации — весь спектр уязвимостей веба (OWASP TOP 10).

Проверки логики работы веб-приложения

Тестирование логики работы приложения на стороне клиента. Тестирование на т.н. «состояние гонки» — race condition. Тестирование доступности информации исходя из прав доступа или его отсутствия. Проверка возможности дублирования или разделения данных. На этом этапе нам понадобится хорошо изучить логику работы приложения и эксплуатация с помощью Burp Suite, OWASP ZAP или все той же mantra. Выявление таких уязвимостей в автоматическом режиме практически невозможно (кроме утилит работы с кодом для выявления формальных признаков такого рода уязвимостей и изучения исходного кода).

Проверка серверного окружения

Проверка архитектуры сервера. Поиск и выявление публичных уязвимостей. Проверка серверных учетных записей (службы и сервисы). Определение настроек сервера или компонентов (SSL и т.д.). Проверка прав доступа. Здесь можно воспользоваться как специализированными сканерами (под сервис), так и общеизвестными, например такими как OpenVAS, Armitage/Metasploit.

Итого

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

В комментариях буду рад ответить на ваши вопросы.