Инструменты тестирования безопасности API: четыре категории, разные задачи

Инструменты тестирования безопасности API: четыре категории

Четвёртая — поведенческая проверка: отклоняет ли API то, что должен отклонять. Вызовы без аутентификации, доступ к чужим аккаунтам, границы ролей, просроченные токены. Ни один сканер этого не проверит, потому что всё это зависит от того, что в вашем продукте означает «разрешение».

Чего не хватает большинству команд

Обычно у команды есть сканер в пайплайне и тест на проникновение раз в год. Полезно и то и другое. Но ни то ни другое не проверяет, что эндпоинт, выкаченный в прошлый вторник, действительно контролирует авторизацию на уровне объектов, — а именно эту уязвимость в реальных API эксплуатируют чаще всего.

Причина, по которой это остаётся непроверенным, организационная, а не техническая. Выглядит как вопрос безопасности — значит, ждёт процесса безопасности, а тот запускается раз в квартал. На самом деле это поведенческая проверка, и её место в наборе тестов, который прогоняется на каждое изменение.

Как понять, какой пробел у вас

• Вспомните ли вы, когда в последний раз кто-то проверял, что пользователь A не может прочитать данные пользователя B? Если ответ — «на ежегодном тесте на проникновение», то у самой вероятной вашей уязвимости есть окно в двенадцать месяцев.

• Получает ли новый эндпоинт проверку прав доступа автоматически? Если это зависит от того, вспомнит ли автор, её пропустят.

• Находки сканера разбираются или накапливаются? Сканер, отчёты которого никто не читает, хуже, чем его отсутствие: он создаёт видимость покрытия.

Как закрыть поведенческий пробел

Сгенерированные планы для API включают категории авторизации и граничных значений, поэтому проверки прав существуют рядом с функциональным покрытием, а не отдельным мероприятием. Это переводит их в ритм «на каждое изменение» — единственный ритм, который успевает за новыми эндпоинтами.

Ту же настройку можно выполнить в панели TestSprite, если вы предпочитаете ничего не устанавливать локально. Остальные возможности CLI описаны в репозитории CLI.

Как это устроено — в документации по тестированию API.

Разбор находок, или почему сканер перестал что-либо значить

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

Первый запуск выдаёт длинный список, значительная часть которого к вам не относится. Разбирать его некогда, поэтому его просматривают по диагонали. Следующий запуск выдаёт тот же список плюс два новых пункта, которых не видно в уже существующем шуме. За квартал отчёт превращается в артефакт, который генерируется и уходит в архив, и настоящая находка может пролежать в нём год.

Решение неэффектное: один раз как следует разобрать первый список и заглушить неприменимое, письменно указав причину. После этого отчёт показывает только то, что изменилось, — а такое люди действительно читают. Сканер без разбора находок хуже, чем его отсутствие, потому что создаёт видимость покрытия.

Что и где запускать

Поведенческие проверки — на каждый пул-реквест. Сканеры — по расписанию. Прокси и фаззеры — в руках того, кто ведёт целенаправленную работу. Тест на проникновение — когда меняется модель угроз, а не когда подошёл срок по календарю.

Если пайплайн принадлежит другой команде, то GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда ваша сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, с этим справится шаг GitHub Actions .

Что TestSprite даёт в четвёртой категории

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

Работа идёт с запущенным сервисом через его интерфейс: что именно существует, определяется по проходу обнаружения и вашей спецификации. Auto-Authentication поддерживает сессии живыми на протяжении прогона, Dynamic Variables переносят значения между вызовами, Dependency Chains выводят порядок выполнения из того, что каждому кейсу нужно и что он производит, а Auto-Cleanup удаляет ровно то, что прогон создал.

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