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

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

  1. Тестирование: введение и задачи
  2. Сбор информации с помощью поисковых систем
  3. Определение веб-сервера
  4. Поиск информации в метафайлах веб-сервера
  5. Определение веб-приложений на сервере
  6. Поиск утечек информации в комментариях и метаданных
  7. Определение точек входа веб-приложения

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

Резюме

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

Задачи

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

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

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

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

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

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

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

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

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

Пример:

OWASPZAPSP

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

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

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

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

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

Справочные материалы:

[1] http://en.wikipedia.org/wiki/Code_coverage