Чек-лист тестирования безопасности API: кто и что проверяет

Чек-лист тестирования безопасности API, сгруппированный по тому, кто выполняет проверку

Закрывается автоматической функциональной проверкой

Это поведенческие проверки: правильно ли API отвечает на запрос, который должен отклонить. Их место — в вашем обычном наборе тестов, и запускаться они должны при каждом изменении.

• Доступ без аутентификации отклоняется. Каждый защищённый эндпоинт при вызове без учётных данных возвращает корректный отказ, а не данные.

• Авторизация проверяется на уровне каждого объекта. Пользователь A не может прочитать или изменить записи пользователя B, подставив другой идентификатор в путь. Это самая часто эксплуатируемая уязвимость в реальных API — и при этом обычная поведенческая проверка.

• Границы ролей соблюдаются. Роль только для чтения не может писать. Просроченный или отозванный токен отклоняется.

• Валидация входных данных отклоняет значения вне допустимого диапазона. Граничные случаи по каждому параметру, включая те, которые никто не документирует.

• Ошибки не раскрывают внутреннее устройство. Стек-трейсы, фрагменты запросов и внутренние имена хостов не попадают в ответы.

Требует сканера или специализированного инструмента

• Уязвимости зависимостей и библиотек.

• Классы инъекций: SQL, командные, шаблонные, десериализация.

• Конфигурация TLS и работа с сертификатами.

• Проверка вашего стека на известные CVE.

Требует человека

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

• Моделирование угроз и решение о том, какие данные на самом деле являются чувствительными.

• Всё, что требует фантазии на тему того, как кто-то станет использовать ваш продукт не по назначению.

Пункт, который пропускают

Авторизация на уровне объектов — пункт, которого чаще всего не хватает и который проще всего проверить. Создайте две учётные записи, из-под одной создайте запись и попробуйте прочитать её с токеном второй. Если в ответ пришли данные, у вас самая распространённая серьёзная уязвимость API в отрасли — и находит её один тест.

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

Как заставить автоматизируемую половину действительно запускаться

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

Панель управления закрывает то же самое для тех, кому не нужна локальная установка, а полный набор команд — в репозитории CLI.

Механика описана в документации по тестированию API.

Две учётные записи, которые стоит держать постоянно

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

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

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

Периодичность по группам

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

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

Как TestSprite закрывает автоматизируемую треть

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

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

Ценность здесь в регулярности, а не в изощрённости. Такие проверки нетрудно написать — трудно вспомнить о них на сороковом эндпоинте. Именно то, что они генерируются и выполняются постоянно, закрывает самую часто эксплуатируемую брешь в реальных API, не добавляя процесса, которому кто-то обязан следовать.