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

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

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

Определение точек входа веб-приложения

Резюме

Определение точек входа веб-приложения и возможных векторов для атаки — ключевой процесс, перед тем как будет проведено какое-либо тестирование, так как это позволяет пентестеру определить возможные слабые места.

Задачи

Понять каким образом формируются запросы, и как на эти запросы отвечает приложение.

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

Прежде чем начать тестирование, пентестеру необходимо понимать структуру и принципы функционирования приложения, как пользователь и браузер взаимодействуют с приложением. По мере изучения веб-приложения, тестировщик должен уделять пристальное внимание всем HTTP запросам (GET и POST) а также параметрам и полям форм, передаваемым в запросах. Кроме этого, следует обратить внимание на то, в каком случае при передаче параметров в приложение используются GET запросы, а в каком —  POST запросы. Обычная практика — для взаимодействия с приложением использовать GET запросы, но при этом важная пользовательская информация передается в теле POST запроса.

Для того чтобы увидеть параметры POST запроса, тестировщику необходимо использовать специальный инструмент — intercepting proxy (перехватывающий прокси), (например, OWASP Zed Attack Proxy (ZAP) — ссылка) или специальный плагин браузера. Также при анализе параметров POST запроса, необходимо особое внимание обращать на скрытые поля форм, передаваемые в запросе, обычно такие параметры содержат важную информацию: состояние, количество предметов, цену — параметры, которые по замыслу разработчика не должны видеть или изменять.

По опыту автора (авторов OWASP Testing Guide), на этой стадии тестирования очень удобно использовать перехватывающий прокси и табличный редактор. Прокси сохраняет каждый запрос и ответ на него по мере того, как вы исследуете веб-приложение. Также, имея все запросы и ответы от приложения, тестировщик может видеть каждый заголовок, каждый параметр и т.д., передаваемые в приложение и возвращаемые пользователю. Такой подробный процесс изучения веб-приложения может быть довольно утомительным и скучным, особенно на больших интерактивных сайтах ( банковское приложение). Однако, опыт подскажет на что необходимо обращать более пристальное внимание и данный этап может быть значительно сокращен.

По мере изучения веб-приложения, тестировщику следует помечать различные интересные параметры запросов, заголовки  и сохранять их в таблицу. В таблицу также следует включать URL запрошенной страницы (неплохо будет включить номер запроса из прокси для дальнейшего анализа), интересные и необычные параметры запросов, тип запроса (POST, GET), требуется ли аутентификация, используется ли SSL, является ли запрос частью какого-либо процесса, состоящего из нескольких шагов (процесс восстановления пароля). После того как тестировщик задокументировал все разделы веб-приложения, можно приступать к тестированию каждого раздела. Остальная часть этого гайда посвящена описанию тестирования различных разделов веб-приложения, но данный шаг по определению всех ключевых разделов приложения должен быть завершен перед началом подробного тестирования.

Ниже представлены некоторые аспекты, которым стоит уделить особое внимание при исследовании запросов и ответов приложения. GET и POST запросы используются в веб-приложениях чаще всего, но иногда встречаются также PUT и DELETE методы, это довольное редкие методы, на них также стоит обратить пристальное внимание, так как часто именно они ведут к уязвимостям.

Запросы:

  • определить, где используются GET запросы, а где POST;
  • определить все параметры, используемые в теле POST запросов;
  • для POST запросов уделить особое внимание различным скрытым полям веб-форм;
  • определить все параметры, используемые в GET запросе;
  • определить все параметры, используемые в строке запроса, они обычно представлены как пары: foo=bar, также имейте ввиду что в строке запроса может быть несколько параметров, разделенных знаками & ~ :;
  • также при наличии нескольких параметров в запросе, необходимо отметить, все ли передаваемые параметры необходимы для корректного выполнения запроса (или атаки). Тестировщику необходимо точно определить все параметры запроса, даже если они закодированы или зашифрованы, определить, какие конкретно параметры обрабатываются приложением. Как протестировать такие параметры изложено в дальнейших главах этого гайда, на данном этапе достаточно просто определить наличие всех параметров запросов;
  • также стоит обратить внимание на присутствие всяческих нетипичных дополнительных заголовков (напр debug=False).

Ответы:

  • определить, где и когда добавляются или модифицируются значения куков (заголовок Set-Cookie);
  • определить, есть ли редиректы (3хх HTTP статус коды), есть ли 400 статус коды, в частности 403 Forbidden, и есть ли 500 статус код Internal server error;
  • обратить внимание на различные интересные и нетипичные заголовки, например, «Server: BIG-IP» говорит о наличии балансировщика нагрузки. Таким образом, если один из серверов балансировщика настроен некорректно, тестировщик может сделать несколько запросов, чтобы получить доступ к уязвимому серверу.

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

Ниже представлены два примера, демонстрирующие принцип изучения веб-приложения.

Пример 1
В этом примере используется GET запрос, который совершает покупку предмета в онлайн магазине:

GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM=z101a&PRICE=62.50&IP=x.x.x.x
Host: x.x.x.x
Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIGZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy

Ожидаемый результат:
Тестировщику следует отметить все параметры запроса, CUSTOMERID, ITEM, PRICE, IP, а также куки (в данном случае это могут быть какие-либо закодированные параметры или же просто данные сессии)

Пример 2
В данном примере показан POST запрос, который выполняет авторизацию пользователя в приложении:

POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login
Host: x.x.x.x
Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIHByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIzNA==
CustomCookie=00my00trusted00ip00is00x.x.x.x00

Тело POST запроса:
user=admin&pass=pass123&debug=true&fromtrustIP=true

Ожидаемый результат:
В данном случае тестировщику следует отметить все передаваемые параметры, также пометить что они передаются в теле POST запроса, отметить использование кастомных кук.

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

Тестирование по методу серого ящика включает в себя все из «черного ящика» с небольшим дополнением. Если приложение может принимать данные из других источников (SNMP трапы, syslog сообщения, SMTP или SOAP от других серверов), обсуждение с разработчиками приложения поможет выявить функционал, который принимает и обрабатывает такие данные. Например, разработчики могут помочь с формированием правильного SOAP запроса к веб-приложению.

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

Перехватывающие прокси:

Плагины браузера:

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

RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 — http://tools.ietf.org/html/rfc2616