Перевод OWASP Testing Guide. Часть 1.8.

Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет о составлении карты веб-приложения.

Предыдущие статьи:

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

Резюме

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

Задачи

Составить карту веб-приложения и понять принципы его функционирования.

Как тестировать

Используя методологию тестирования черным ящиком, довольно сложно протестировать всю кодовую базу. Это связано не столько с тем, что тестировщик не имеет доступа к коду приложения, сколько с тем, что тестирование всего приложения — очень затратный по времени процесс.

Существует несколько подходов к тестированию и измерению покрытия кода:

Path — тестирование каждого пути в рамках приложения, включающее комбинаторные и граничные проверки значений для каждого пути. Такой подход весьма тщательный, но количество тестируемых путей растет экспоненциально с добавлением нового параметра для тестирования.
Data flow — тестирование путей и переменных приложения с точки зрения пользователя, уделяет особое внимание процессу передачи и использования данных при работе приложения.
Race — тестирование, подразумевающее изменение одних и тех же параметров и входных данных одновременно для нескольких параллельно выполняющихся инстансов приложения.

Тестирование по методу черного ящика

Можно начать с документирования всех ссылок и путей исполнения приложения, обнаруженных при исследовании приложения (spidering, как ручной так и автоматический). Затем, можно проанализировать более подробно точки принятия решений (“развилки”). Все собранные данные необходимо задокументировать, чтобы можно было предоставить владельцу веб-приложения документ, описывающий пути исполнения, покрытые тестами.

Тестирование по методу серого/белого ящика

При методологии тестирования серым/белым ящиком, гораздо проще добиться более полного покрытия приложения.

Пример:

Автоматическое исследование приложения (spidering)

“Паук” — инструмент для автоматического исследования ресурсов (URLs) приложения. Он начинает свою работы со списка ссылок (называемых seed, сид), которые необходимо посетить, затем автоматически следует ссылкам, встречающимся на веб-страницах, таким образом обнаруживая возможные пути исполнения приложения. В примере используется Zed Attack Proxy (ZAP)

ZAP может работать в следующих режимах, в зависимости от настроек:

Spider site — сид лист содержит все уже обнаруженные URL выбранного сайта
spider subtree — сид лист содержит все уже обнаруженные URL для выбранной ветки сайта
spider URL — сид лист содержит только URL, относящиеся к соответствующей ноде для выбранной ветки сайта
spider all in scope — сид лист содержит только URL, которые выбрал пользователь.

Инструменты: