Тестирование API с ИИ: OpenAPI и GraphQL

Современные приложения это тонкий фронтенд над API, и настоящие баги часто именно в API. Хорошая новость для тестировщика в том, что API склонны описывать сами себя: REST-API отдают спецификации OpenAPI, а GraphQL-API отвечают на introspection-запросы. И то и другое даёт карту, которую может прочитать модель. Этот пост продолжает тестирование частых веб-багов и ведёт к сборке hackbot.

#API ломаются иначе

OWASP API Security Top 10 ставит авторизацию на первое место. Первыми стоит выучить два: broken object level authorization, где вы дотягиваетесь до объекта другого пользователя, и broken function level authorization, где вы вызываете админское действие как обычный пользователь. Оба это API-версия багов контроля доступа из прошлого поста, и оба частые, потому что у API много endpoints, и один из них обычно забывает про проверку.

#Найдите спецификацию OpenAPI

Многие API публикуют свою спецификацию. Частые расположения это /openapi.json, /swagger.json, /v1/openapi.json или страница документации, которая её загружает. Скачайте её, и у вас в одном файле каждый путь, метод, параметр и схема.

curl -s https://api.example.com/openapi.json -o openapi.json

Отдайте спецификацию модели и попросите перечислить endpoints, отметить те, что читают или пишут объекты пользователей, и выделить те, чьи имена намекают на админскую или внутреннюю роль. Этот проход по чтению превращает длинный документ OpenAPI в ранжированный список того, что тестировать первым.

#Introspection в GraphQL

GraphQL-API обычно отвечает на introspection-запрос, который возвращает всю его схему: каждый тип, поле, query и mutation. Когда introspection включён, вы получаете всю поверхность атаки одним запросом.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

Передайте схему модели и попросите сгруппировать queries и mutations, выбрать те, что трогают данные других пользователей, и назвать аргументы каждого. Спецификация GraphQL описывает introspection, а в OWASP Web Security Testing Guide есть раздел о тестировании GraphQL.

#Пусть модель планирует, потом тестируйте руками

По любой из карт попросите у модели короткий план тестов: для каждого endpoint с объектами, какие два аккаунта взять и какой id поменять; для каждой привилегированной операции, из какой сессии с малыми правами её попробовать. Модель хорошо превращает схему в такой чек-лист. Сказать, действительно ли проверка отсутствует, она не может, поэтому каждый случай вы прогоняете через свой proxy с подконтрольными аккаунтами и читаете результат. Mutation, которая позволяет обычному пользователю изменить чужую запись, это чистая BOLA, доказанная двумя сессиями.

#Проверяйте и храните доказательства

Находки в API легко доказать и легко завысить. Доказывайте их подконтрольными аккаунтами, по одной переменной за раз, и сохраняйте полный request и response по каждому. Для BOLA доказательство это два request: ваш объект, потом объект второго аккаунта, возвращённый в вашу сессию. Для BFLA это успешный привилегированный вызов из сессии, которой он не положен. Держите внутренние данные, до которых вы дошли, в минимуме, нужном, чтобы показать impact, и описывайте только то, что продемонстрировали.

#Замечание про автоматизацию и частоту запросов

API соблазняют заскриптовать сотни запросов. Сначала проверьте правила программы по автоматизации и частоте запросов, держите объём низким на боевой цели и гоняйте тяжёлые итерации на локальной копии. API, который вы молотите, это API, чей владелец замечает вас не с той стороны.

#Дальше в этой серии

Теперь вы прошли весь цикл руками. Следующие три поста собирают небольшой агент, который проходит шаги recon и тестирования за вас, под вашим подтверждением. Начните с архитектуры hackbot.