Перейти к содержанию

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

Резюме

Перед проведением тщательного тестирования важно перечислить приложение и его уязвимые места. Это позволяет тестировщику выявить возможные слабые места. В этом разделе мы поможем вам определить и визуализировать области приложения, которые нужно исследовать после завершения этапа перечисления.

Цели тестирования

  • Определить возможные точки входа и инъекции через анализ запросов и ответов.

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

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

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

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

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

Запросы

  • Определите, где используются GET и POST.
  • Определите все параметры, используемые в POST-запросе (они находятся в теле запроса).
  • Обратите внимание на скрытые параметры в POST-запросах. Все поля формы (включая скрытые параметры) отправляются в теле HTTP-сообщения к приложению и обычно не видны без прокси или просмотра исходного кода HTML. Также данные на следующей странице могут отличаться в зависимости от значений скрытых параметров.
  • Определите все параметры, используемые в GET-запросах (например, в URL), особенно в строке запроса (обычно после знака ?).
  • Обратите внимание на все параметры в строке запроса. Они обычно имеют пару формата, например, foo=bar. Также учтите, что в одной строке запроса может быть много параметров, разделенных &, ~, :, или любым другим специальным символом или кодировкой.

Важно помнить, что для выполнения атак могут понадобиться все или некоторые параметры, поэтому тестировщик должен определить все параметры (даже закодированные или зашифрованные) и выяснить, какие из них обрабатываются приложением. Позже в руководстве будут описаны методы тестирования этих параметров. На этом этапе просто убедитесь, что каждый из них определен. Обратите внимание на любые дополнительные или пользовательские заголовки, которые обычно не встречаются (например, debug: false).

Ответы

  • Определите, где устанавливаются новые куки (заголовок Set-Cookie), изменяются или добавляются.
  • Обратите внимание на редиректы (статус-коды 3xx), коды 400, особенно 403 Forbidden и 500 Internal Server Error в обычных ответах (т.е. при неизмененных запросах).
  • Также запишите любые интересные заголовки. Например, заголовок Server: BIG-IP указывает, что сайт использует балансировку нагрузки. Если один сервер неправильно настроен, тестировщику может потребоваться сделать несколько запросов для доступа к уязвимому серверу в зависимости от типа используемой балансировки нагрузки.

Черный ящик: тестирование точек входа приложения

Ниже приведены два примера, как проверить точки входа приложения.

Пример 1

Пример GET-запроса для покупки товара в онлайн-магазине:

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

Тестировщик должен записать все параметры запроса, такие как CUSTOMERID, ITEM, PRICE, IP и куки (которые могут быть закодированными параметрами или использоваться для состояния сессии).

Пример 2

Пример POST-запроса для входа в приложение:

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

user=admin&pass=pass123&debug=true&fromtrustIP=true

Тестировщик должен записать все параметры, как и раньше, но большинство из них передаются в теле запроса, а не в URL. Обратите внимание на пользовательский HTTP-заголовок (CustomCookie).

Серый ящик: тестирование точек входа приложения

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

Инструмент OWASP Attack Surface Detector

Инструмент Attack Surface Detector (ASD) исследует исходный код и выявляет конечные точки веб-приложения, параметры, которые они принимают, и тип данных этих параметров. Это включает в себя недоступные конечные точки, которые паук не сможет найти, или необязательные параметры, которые полностью не используются в клиентском коде. Также он может рассчитывать изменения в уязвимых местах между двумя версиями приложения.

ASD доступен как плагин для OWASP ZAP и Burp Suite, а также доступен как инструмент командной строки. Инструмент командной строки экспортирует уязвимую поверхность в виде JSON, который затем можно использовать плагином ZAP и Burp Suite. Это полезно в случаях, когда исходный код не предоставляется тестировщику. Например, тестировщик может получить файл JSON от клиента, который не хочет предоставлять исходный код.

Как использовать

JAR-файл CLI доступен для скачивания по ссылке: Attack Surface Detector CLI Releases.

Вы можете выполнить следующую команду для ASD, чтобы выявить конечные точки из исходного кода целевого веб-приложения:

java -jar attack-surface-detector-cli-1.3.5.jar <source-code-path> [flags]

Пример выполнения команды против OWASP RailsGoat:

$ java -jar attack-surface-detector-cli-1.3.5.jar railsgoat/

Вывод команды включает в себя обнаруженные конечные точки и параметры, с которыми они работают.

Для включения логирования используйте аргумент -debug. Вы также можете сгенерировать файл JSON, используя флаг -json, который можно использовать плагином для ZAP и Burp Suite.

Инструменты

  • OWASP Zed Attack Proxy (ZAP)
  • Burp Suite

Выводы

  • Определение точек входа в приложение имеет решающее значение для понимания его структуры и уязвимостей.
  • Используйте прокси-инструменты для сбора информации о запросах и ответах.
  • Зафиксируйте все параметры и возможные уязвимости в таблице для дальнейшего анализа.
  • Инструмент Attack Surface Detector поможет в анализе исходного кода и выявлении дополнительных уязвимых мест.