Рис.11.9. Пример запроса Postman к API

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

Вышестоящий прокси-сервер

Postman также поддерживает маршрутизацию запросов через системный прокси-сервер или пользовательский сервер. Использование Burp или OWASP ZAP в данном случае – мудрый выбор. Как только мы импортируем и запускаем коллекцию,каждый запрос будетперехватываться и будетготов к проверке

иповторному воспроизведению.

Вразделе File (Файл) и далее в Settings (Настройки) есть вкладка Proxy (Прокси-сервер), которая должна позволить нам указать локальный проксисервер Burp, 127.0.0.1 на порту 8080 по умолчанию (см. рис. 11.10).

Все наши последующие запросы в Postman будут также отображаться на

вкладке HTTP history прокси-сервера Burp (см. рис. 11.11).

Рис.11.10. Конфигурация вышележащего прокси-сервера Postman

Рис.11.11. Burp показывает запросы,сгенерированные Postman

Среда выполнения

ДлясозданияэффективныхколлекцийнужносоздатьновуюсредувыполненияPostmanдлякаждогоцелевогоAPI. СредывыполненияPostmanпозволяют хранитьданныевпеременных,которыебудутполезныдлятакихдействий,как передача токенов авторизации между запросами в коллекции. Чтобы создать

Рис.11.14. Указание среды выполнения для запроса

Коллекции

Как уже было сказано, коллекция – это просто список API-запросов в определенной последовательности. Их можно экспортировать в JSON и импортировать в любой клиент Postman,что делает их действительно переносимыми.

Чтобы продемонстрировать всю мощь коллекций Postman, создадим коллекциюдляэкземпляранашегоуязвимогоAPI,api.ecorp.local,работающего на порту 8081.

Если посмотрим документацию по уязвимому API от Мэтта Вальдеса (Matt Valdes), то заметим, что для большинства взаимодействий требуется токен авторизации, передаваемый через пользовательский HTTP-заголовок X-Auth-Token. Хотя большинство RESTful API пытается использовать заголовок Authorization для токенов, пользовательские заголовки не так уж редки. Такие инструменты, как Burp и Postman, идеально подходят для тестирования безопасности, поскольку бóльшую часть работы можно автоматизировать,даже когда сталкиваемся с отклонениями от нормы.

Документацию можно найти в файле README.md на странице https://github.com/mattvaldes/vulnerable-api.

В документации говорится, что можно получить новый токен, если отправить POST-запрос в /tokens,тело которого содержит данные аутентификации в формате JSON. Учетные данные по умолчанию: user1 и pass1. Тело нашего запроса на аутентификацию должно выглядетьтак:

{

"auth": { "passwordCredentials": {

"username": "user1", "password": "pass1"

}

}

}

Рис.11.16. Создание новой коллекции

Во всплывающем окне можно ввести имя и описание, если необходимо, прежде­ чем нажать кнопку Create (Создать).

Рис.11.17. Создание новой коллекции

Все сделанные нами запросы записываются на вкладке История в рабочей области.

Мы можем выделить те, которые нам нужны для коллекции, и нажать кнопку Save (Сохранить) рядом с кнопкой Send (Отправить) в правом верхнем углу.

Рис.11.18. Сохранение запросов в коллекцию

ВнижнейчастимыдолжныувидетьнашуновуюколлекциюECorpAPI.Можно выбрать ее для сохранения наших запросов.

Рис.11.19. Выбор нужной коллекции

Повторите этот процесс для любых запросов, которые должны войти в эту коллекцию.При запуске ожидаем,что наша коллекция получит новый токен в первом запросе и выполнит второй аутентифицированный запрос к /user/1, используя предоставленный токен.

Рис.11.20. Аутентифицированный запрос Postman

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

Для этого нам нужно использовать функцию Postman под названием Tests (Тесты).Каждыйзапроснастроимнавыполнениетестовивыполнениекакогото действия. Как правило, они могут использоваться для того, чтобы проверить,быллизапрос.Разработчикимогутиспользоватьтесты,чтобыубедиться, что код, который они только что добавили, ничего не испортил.

Тесты пишутся на JavaScript, поэтому необходимо некоторое количество знаний в области программирования. К счастью, существуют уже готовые тес­ ты, которые мы можем использовать.

Для нашего запроса Get Auth Token в коллекции ECorpAPIтестдолжен проверить ответ, проанализировать его как JSON и извлечь идентификатор токена. Чтобы передать его другому запросу, можно использовать среду ECorp API и сохранить данные в переменной,которую мы называем auth_token.

Код для достижения этой цели довольно прост, хотя и выглядит немного странно, если вы не знакомы с JavaScript. Каждая запись pm.test является отдельным тестом, который должен быть выполнен в указанном порядке. Если какой-либо из тестов не будет пройден, мы увидим предупреждение.

pm.test("Status code is 200", function () { pm.response.to.have.status(200);

});

pm.test("Save Auth Token", function () { var data = pm.response.json();

pm.environment.set("auth_token", data['access']['token']['id']); });

Первый тест просто проверяет наличие ответа 200 отAPI.Все остальное вызовет ошибку во время запуска коллекции.

Второй тест выполнит парсинг текста ответа с помощью метода json() и сохранитего влокальной переменной data.Если вы помните иерархию ответа

пользуя нотацию массива JavaScript: data['access']['token']['id'].

Используя функцию pm.environment.set, сохраняем значение id в переменной среды auth_token,делая его доступным для других запросов.

Каждыйразпривыполненииэтогозапросавданнойколлекциипеременная auth_token будетобновляться.Среды можно проверить,щелкнув значок глаза рядом с именем.

Рис.11.21. Изучение среды Postman

Наш второй запрос к /user/1 требует, чтобы мы передали это значение через заголовок X-Auth-Token. Добавляем новый пользовательский заголовок и для этого значения извлекаем список существующих переменных, набирая {{ в поле Value (Значение). Postman автоматически заполнит имеющиеся переменные за нас.

Рис.11.22. Использование переменных среды в запросах