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

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

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

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

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

Далее я опишу этапы и утилиты, которые подходят к каждому из них.

Разведка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестирование веб-приложения может быть выполнено как в инструментальном (w3af ^[13], vega ^[14], arachni ^[15], sqlmap ^[16], Acunetix, Netsparker и.д.), так и полу-инструментальных — Burp Suite ^[17], OWASP ZAP ^[18] и д.р.

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

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

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

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

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

Итого

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

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

Автор: LukaSafonov

Источник ^[21]