По теме: как стать AppSec-инженером, OWASP Top 10 на пальцах, аудит API в стартапе, тестирование GraphQL, менторинг.
API давно стали главной целью атакующих. Не потому, что они какие-то особенно слабые, а потому, что их стало слишком много и за большинством никто толком не следит. Каждый сервис, мобильное приложение и интеграция с партнёром — это ещё десяток эндпоинтов, про которые через полгода помнит только git-история.
Цифры это подтверждают. По данным Wallarm, только за второй и третий кварталы 2024 года количество уязвимостей в API выросло на 21%. Треть из них (32%) приходится на облака и cloud-native приложения. Самое неприятное — у большинства этих уязвимостей оценка CVSS 7.5 и выше, то есть речь о критических проблемах, а не о мелочах.
Я разобрал материал Dark Reading на эту тему и собрал четыре корневые причины, из-за которых компании реально ломают. Под каждой — что именно делают не так и как это чинить.
Почему API стали главной целью
Отчёт Imperva State of API Security даёт масштаб проблемы. API-трафик — это уже 71% всего веб-трафика. Средняя компания делает порядка 1,5 миллиарда API-вызовов в год и держит в среднем 613 эндпоинтов на аккаунт. При таких объёмах атакующему не нужно искать сложный вектор: достаточно одного забытого эндпоинта без авторизации.
Nick Rago, Field CTO в Salt Security, формулирует это прямо: в подавляющем большинстве инцидентов барьер для взлома был очень низким, и атакующему не приходилось прилагать героических усилий. Это важная мысль для всей статьи: компании ломают не через гениальные эксплойты, а через базовые вещи, которые никто не проверил.
Дыра 1: неправильно настроенные API
Это причина номер один всех крупных сливов последних лет, и она же самая обидная. API работает, бизнес доволен, но конфигурация оставляет открытые двери, которые находятся простым перебором.
Типовой набор ошибок выглядит так:
- Нет проверки прав на уровне объекта (BOLA/IDOR). Вы запрашиваете
/invoices/123— это ваш счёт. Меняете на/invoices/124— чужой, но API спокойно его отдаёт. - Нет нормальной аутентификации. Эндпоинт просто забыли закрыть: он был внутренним, потом стал внешним, а проверку токена так и не добавили.
- Нет rate limiting. Можно перебирать ID, логины и коды подтверждения без остановки — сервер ничего не ограничивает.
- В ошибках торчат внутренности. Стек-трейсы, SQL-запросы и внутренние IP-адреса прямо в теле ответа — готовая карта для атакующего.
Как это чинить. Проверяйте права доступа на каждый объект, а не только на входе в API: авторизованный пользователь — ещё не владелец конкретного ресурса. Используйте ролевую модель (RBAC) и MFA для чувствительных операций. Фильтруйте ответы на сервере и не отдавайте клиенту лишние поля. И ставьте rate limiting везде, где есть ID, логин или поиск.
Дыра 2: плохо спроектированные API
Здесь уже не ошибка конфига, а ошибка мышления. API делает ровно то, что задумано, но задумано так, что этим можно злоупотребить. Формально всё работает, тесты зелёные, а дыра — архитектурная.
Классические примеры из практики:
- API возвращает больше данных, чем нужно интерфейсу. Клиентское приложение показывает три поля, а в ответе их тридцать — и чужую базу можно годами скрапить легальными запросами.
- Эндпоинт принимает непроверенный ввод или отдаёт детали реализации, по которым легко строить следующие атаки.
- Бизнес-логика никак не защищена: можно поменять цену товара в корзине, применить два несовместимых купона или отправить
amount=-1000и получить деньги вместо списания.
Именно злоупотребление бизнес-логикой — главный тренд последних лет. По отчёту Imperva State of API Security 2024, на такие атаки пришлось 27% всех атак на API в 2023 году, и это на 10% больше, чем годом раньше. Сканер такие вещи не находит в принципе: с точки зрения протокола запрос полностью корректен.
В Salt Security приводят точное сравнение: плохой дизайн API — это как построить больницу без чертежей, а потом удивляться, что пациенты падают в шахту лифта. Чинится это не патчем, а процессом: думать о безопасности на этапе дизайна, а не после релиза, и добавлять поведенческую защиту, которая отличает аномальное использование от нормального.
Дыра 3: отсутствие видимости
Вернёмся к цифре из отчёта Imperva: в среднем 613 эндпоинтов на аккаунт. Теперь честный вопрос: кто в компании знает их все? На практике — никто. Инвентаризации нет, а OpenAPI-спека описывает в лучшем случае то, что команда помнит.
Отсюда растут shadow APIs — эндпоинты, которых нет ни в одной документации. Старые версии v1, которые забыли выключить после релиза v2. Бета-эндпоинты, которые выкатили без аутентификации «на недельку, для теста». Служебные ручки, которые торчат наружу, потому что так было быстрее.
Самый известный пример — слив Optus в Австралии: данные 9,7 миллиона клиентов утекли через незадокументированный эндпоинт без авторизации. Его не было ни в одной OpenAPI-спеке, поэтому его никто и не проверял. Kimm Yeo из Black Duck объясняет, почему это системная проблема: сегодняшние решения ищут API уже в продакшене, и когда приходит критический алерт, его невозможно отследить до конкретного кода.
Что делать. Вести инвентаризацию всех внешних API, а не только тех, что попали в Swagger. Искать свои же эндпоинты так, как их ищет атакующий: сканировать JS-бандлы, поддомены и Shodan. И делать это до продакшена, на этапе разработки, а не после первого инцидента.
Дыра 4: недостаточное тестирование безопасности
По опросу Postman, только 37% организаций формально встроили проверки безопасности в жизненный цикл API. Те же 37% делают автоматические сканы и регулярные пентесты. Остальные две трети рынка по сути надеются, что пронесёт.
Правильно делают те, кто работает по принципу spec-first. Сначала чертёж API в OpenAPI/Swagger, потом аппрув архитектуры с участием безопасности, и только после этого код. В Salt Security продолжают свою аналогию: сначала нужно начертить больницу и проверять строительство по плану, прежде чем пускать туда пациентов. Звучит очевидно, но в большинстве компаний процесс до сих пор устроен наоборот.
Если вы хотите научиться проводить такие проверки руками — перехват трафика, подмена ID, работа с токенами и понятный отчёт, — я подробно разобрал этот путь в статье как стать Application Security Engineer. А живой пример полного цикла проверки есть в разборе аудита API в стартапе.
Итог: два исхода и база защиты
Какой бы ни была конкретная уязвимость, все риски API сводятся к двум исходам. Первый: кто-то получил доступ к тому, к чему не должен был. Второй: кто-то положил ваш API, и бизнес встал. Всё остальное — вариации.
Защита от обоих исходов начинается с базы, которую, по-хорошему, никто не делает:
- Знайте все свои API, включая старые версии и забытые бета-эндпоинты.
- Знайте, какие из них требуют авторизации, и проверяйте это регулярно, а не один раз при релизе.
- Проверяйте права на сервере, а не на клиенте: скрытая кнопка в UI — это не контроль доступа.
- Ставьте нормальный rate limiting везде, где можно что-то перебирать.
Оригинальный материал: Dark Reading, 1 ноября 2024, автор Jai Vijayan. Цифры — из отчётов Wallarm, Imperva State of API Security 2024 и опроса Postman.
Обучение и контакты
Если вам нужна системная практика по безопасности API — контроль доступа, работа с токенами, поиск shadow-эндпоинтов и профессиональные отчёты, — изучите программу на странице Application Security Engineer.
Составить индивидуальный план подготовки под ваш бэкграунд можно в Telegram: @faroeman. Формат совместной работы подробно описан в разделе менторинг по кибербезопасности.
Ещё по теме: как стать AppSec-инженером, OWASP Top 10 на пальцах, аудит API в стартапе, тестирование GraphQL, менторинг.
Учу AppSec на практике: доступ, API, отчёты, подготовка к найму. Нужен план под ваш бэкграунд? Напишите в Telegram.
Смотреть программу Application Security · пишите в @faroeman.
