4.1.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 /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

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

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

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

OWASP Attack Surface Detector

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

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

CLI jar можно скачать отсюда - https://github.com/secdec/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/
Beginning endpoint detection for '<...>/railsgoat' with 1 framework types
Using framework=RAILS
[0] GET: /login (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_contro
ller.rb (lines '6'-'9')
[1] GET: /logout (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37')
[2] POST: /forgot_password (0 variants): PARAMETERS={email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/
password_resets_controller.rb (lines '29'-'38')
[3] GET: /password_resets (0 variants): PARAMETERS={token=name=token, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/p
assword_resets_controller.rb (lines '19'-'27')
[4] POST: /password_resets (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user=name=user, paramType=QUERY_STRING, dataType=STRING, confirm_password=name=confirm_password, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/password_resets_controller.rb (lines '5'-'17')
[5] GET: /sessions/new (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9')
[6] POST: /sessions (0 variants): PARAMETERS={password=name=password, paramType=QUERY_STRING, dataType=STRING, user_id=name=user_id, paramType=SESSION, dataType=STRING, remember_me=name=remember_me, paramType=QUERY_STRING, dataType=STRING, url=name=url, paramType=QUERY_STRING, dataType=STRING, email=name=email, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '11'-'31')
[7] DELETE: /sessions/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/sessions_controller.rb (lines '33'-'37')
[8] GET: /users (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '9'-'11')
[9] GET: /users/{id} (0 variants): PARAMETERS={}; FILE=/app/controllers/api/v1/users_controller.rb (lines '13'-'15')
... snipped ...
[38] GET: /api/v1/mobile/{id} (0 variants): PARAMETERS={id=name=id, paramType=QUERY_STRING, dataType=STRING, class=name=class, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/api/v1/mobile_controller.rb (lines '8'-'13')
[39] GET: / (0 variants): PARAMETERS={url=name=url, paramType=QUERY_STRING, dataType=STRING}; FILE=/app/controllers/sessions_controller.rb (lines '6'-'9')
Generated 40 distinct endpoints with 0 variants for a total of 40 endpoints
Successfully validated serialization for these endpoints
0 endpoints were missing code start line
0 endpoints were missing code end line
0 endpoints had the same code start and end line
Generated 36 distinct parameters
Generated 36 total parameters
- 36/36 have their data type
- 0/36 have a list of accepted values
- 36/36 have their parameter type
--- QUERY_STRING: 35
--- SESSION: 1
Finished endpoint detection for '<...>/railsgoat'
----------
-- DONE --
0 projects had duplicate endpoints
Generated 40 distinct endpoints
Generated 40 total endpoints
Generated 36 distinct parameters
Generated 36 total parameters
1/1 projects had endpoints generated
To enable logging include the -debug argument

Также вы можете создать json файл , который также может быть использовать в качестве плагина как для Owasp Zap , так и для Burp Suite. Более подробно по ссылкам ниже

• Home of ASD Plugin for OWASP ZAP
• Home of ASD Plugin for PortSwigger Burp

Инструменты

• OWASP Zed Attack Proxy (ZAP)
• Burp Suite
• Fiddler

Материалы для дополнительного чтения

• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1
• OWASP Attack Surface Detector

Перевод подготовлен специально для канала t.me/FreedomF0x

Contact: t.me/freedomf0x t.me/Slippery_Fox twitter.com/FlatL1ne

xmpp(жаба_ёпт): [email protected]

При поддержке друзей: t.me/in51d3 t.me/NeuroAliceMusic t.me/vulnersBot t.me/darknet_prison

Our private (no logs) xmpp server: FreedomFox.im (for add, write to [email protected])

Хорошо там где нас нет (с) Русские хакеры
Добре там де нас немає (с) Російські хакери