Здравствуйте, дорогие друзья.

Согласно Google, “Postman — популярный API-клиент, который упрощает разработчикам создание, совместное использование, тестирование и документирование API. Это достигается за счет того, что пользователи могут создавать и сохранять простые и сложные HTTP/s запросы, а также читать их ответы”. В основном Postman — это инструмент, который можно использовать для чтения и записи документации по API.

● https://www.postman.com/downloads/

Что приятно в Postman, так это то, что вы можете импортировать документацию по API из нескольких источников. Например, ранее мы говорили о Swagger API и использовали официальный веб-сайт swagger api для загрузки документации. Однако вместо этого мы могли бы использовать Postman, все, что вам нужно сделать, это загрузить файл Swagger json, и все готово.

Как только вы импортируете документы API в Postman, все готово. Следующий шаг — просмотреть каждую конечную точку API и протестировать ее на наличие уязвимостей.

WSDL

Согласно Google, “язык описания веб-сервисов (WSDL) — это словарь XML, используемый для описания веб-сервисов на основе SOAP”. Другими словами, файл WSDL используется для описания конечных точек SOAP API.

Как показано выше, файлы WSDL довольно легко обнаружить, просто найдите XML-файл, содержащий тег “wsdl”. При поиске они обычно выглядят как следующие URL-адреса:

● example.com/?wsdl

● example.com/file.wsdl

Как показано выше, затем мы можем импортировать этот файл в инструмент “soupUI”.

● https://www.soapui.org/downloads/soapui/

Этот инструмент можно использовать для создания шаблонов запросов, которые затем можно отправлять на целевой сервер. Все, что вам нужно сделать, это ввести свои значения и нажать «Отправить».

WADL

Согласно Google, “Язык описания веб-приложений (WADL) – это машиночитаемое XML-описание веб-служб на основе HTTP”. Вы можете рассматривать WADL как REST-эквивалент WSDL. WADL обычно используется для REST API, в то время как WSDL обычно используется в конечных точках SOAP.

Файлы WSDL должны выглядеть примерно так, как показано на рисунке выше. При поиске обращайте внимание на XML-документ, заканчивающийся на “wadl”, как показано ниже:

● example.com/file.wadl

Как только у вас будет файл targets WADL, вы сможете импортировать его с помощью postman, как показано выше. Следующим шагом будет ознакомление с документацией по API, чтобы вы могли лучше понять приложение. Это поможет вам в дальнейшем выявлять уязвимости.

Резюме

Документация по API — один из лучших ресурсов, который можно использовать при проверке API на наличие уязвимостей. Если я тестирую конечную точку API, я обычно начинаю с поиска соответствующих документов по API. Это поможет вам лучше понять API и все его функциональные возможности. Как только вы разберетесь с приложением, вы сможете приступить к поиску недостатки дизайна и другие баги устраняются довольно легко.

Вывод

Если вы сталкиваетесь с конечной точкой API, первым делом необходимо выяснить, что это за API. Ваша методика тестирования будет немного отличаться в зависимости от того, какой это API: REST, RPC, SOAP или GraphQL. Обратите внимание, что API-интерфейсы имеют те же уязвимости, что и любое другое веб-приложение, поэтому убедитесь, что вы ищете SQL-инъекции, XSS и все остальные Уязвимости OWASP. Вы также должны внимательно следить за документацией по API, поскольку это может быть очень полезно злоумышленнику. Злоумышленники могут использовать документы API для поиска уязвимостей, скрытых конечных точек и получите лучшее представление о приложении. Кроме того, вы также должны обратить внимание на процесс аутентификации, поскольку в зависимости от технологии может быть несколько способов атаки.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.