В данной статье я расскажу об инструментарии для тестирования безопасности веб-приложений. Основные этапы и чек-лист работ представлены в предыдущей статье.
Большинство утилит можно использовать установив (или запустив в образе виртуальной машины) таких дистрибутивов как: 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, использую заведомо известные учетные данные: таким образом можно выявить защиту от такого рода атак (или ее отсутствие).
Определение требований парольной политики. Здесь ручная проверка логики требований политики. Использование только цифр (например как пин-кода) без защиты от брута — очень плоха идея.
Тестирование восстановления учетной записи. На данном этапе приходится наличие нескольких ссылок или триггеров для сброса пароля, желательно от разных учетных записей. Здесь необходимо будет выявить и определить хеш (частое явление), например с помощью hachID. Далее необходимо произвести сравнение тригеров сброса (например ссылок), с помощью утилит сравнения (например 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.
Итого
Имея план тестирования приложения мы можем шаг за шагом исследовать все его компоненты на наличие тех или иных уязвимостей. Исходя из веб-приложения те или иные пункты могут быть дополнены специфичными для данного приложения проверками или программным обеспечением.
В комментариях буду рад ответить на ваши вопросы.
Автор: LukaSafonov
