Всем привет!
Я, Титов Антон, ведущий эксперт компании Angara Security по направлению защиты веб-ресурсов, расскажу о том, почему защита API не прерогатива WAF и требует дополнительной защиты.
Разработка программ сейчас – это не то же самое, что было десять или двадцать лет назад. Сейчас приложения в большинстве случаев представляют собой целый комплекс архитектурно связанных микросервисов, которые и проще масштабируются, и лучше оптимизируются в отличие от древних монолитов*( монолиты ещё востребованы, и более того, в некоторых случаях (например, для создания прототипов), даже выигрывают). Использование API как раз помогает выстраивать подобные архитектуры, а некоторые команды даже практикуют API-first разработку (приложение разрабатывается сначала с использованием API, а уже потом покрывается Веб-интерфейсом). И, когда вокруг нас такое развитие, мы как безопасники, задаемся вопросом: а достаточно ли защищено приложение, использующее API?
API Gateway: Первый претендент на защиту API
При упоминании API одна из первых ассоциаций - API Gateway. Возникновение этого класса решений - логичный ответ на сложность поддержки разрастающегося количества эндпоинтов: системам нужна «единая точка входа», чтобы планировать маршруты, трансформировать протоколы (из JSON в gRPC и обратно) и вешать базовую авторизацию.
Однако, API Gateway создавался для удобства и производительности, а не для безопасности. Его можно сравнить с крутым диспетчером на проходной: он проверит ваш «пропуск» (валидность токена) и укажет путь к нужному зданию. Но он не станет проверять ваши намерения (авторизацию на уровне данных) и не обыщет ваши сумки на выходе (контроль и валидацию исходящих данных).
Тандем WAF + API Gateway: Вторая проба пера
Логичным продолжением или переосмыслением истории стал тандем WAF + API Gateway. WAF – фильтрует трафик, то есть на него возложена ответственность за защиту, а API Gateway обрабатывает отфильтрованный трафик и маршрутизирует запросы к конечным точкам. Казалось бы, всё отлично, именно так и задумывалось. Но так ли это?
Проблема в том, что WAF нацелен на поиск аномалий внутри запроса — он эффективен против любых инъекций и некорректных заголовков, но практически слеп к злоупотреблению бизнес-логикой. Между тем эксплуатация API предполагает открытость, и зачастую атаки на API как раз связаны с нарушением логики работы программ/приложений, причем в них может вообще отсутствовать какая-либо аномалия с точки зрения WAF. Эту проблему не способен решить и API Gateway, как отмечалось ранее. Приведу пару примеров. Если кто-то медленно, по одной записи в секунду, скачивает вашу данных базу через легитимный эндпоинт, ни WAF, ни API Gateway не поднимут тревогу.
Другой случай - зрелый бизнес с уже сформированным процессом CI/CD, когда разработчики ежедневно выкатывают новые методы API. Для такого бизнеса WAF превращается в обузу: сотрудникам ИБ приходится либо постоянно переписывать правила вручную, либо вовсе игнорировать проблему, оставляя защиту в состоянии «и так сойдет».
Shadow API: «Черный ход», о котором вы забыли
Логичным вопросом станет: «А зачем переписывать правила? Ведь на WAF мы сделали настройки и вносим изменения обычно раз в квартал».
Shadow API – это самая «больная» тема, поскольку это те самые эндпоинты-призраки, которые живут в проде, но их нет ни в одной схеме Swagger.
Откуда они берутся? Забыли снести тестовую ветку, оставили v1 для старого клиента, по-быстрому выкатили фикс в обход пайплайна. Для ИБ-команды этих методов не существует, а значит, они не мониторятся и не прикрыты правилами. Это идеальная точка отправки для взлома. Традиционный методы (WAF-правила) здесь бессильны: вы не можете защитить то, чего не видите в своей панели управления.
Orphan API и Zombie API: братья по несчастью
В дополнение к указанным выше Shadow API добавляются два не менее важных типа уязвимых эндпоинтов:Orphan API – документированный эндпоинт, на который не поступает трафик. Это может свидетельствовать об ошибках разработки – и это звоночек о том, что постепенно теряется контроль над прозрачностью безопасной разработки, а это может вы��иться в более серьезные проблемы.
Zombie API относится к устаревшим API, которые, как все предполагают, были отключены, но на самом деле они всё еще используются. Риски Zombie API аналогичны остальным недокументированным Shadow API, но могут быть даже хуже, поскольку причиной отключения часто являются небезопасные конструкции, которые легче взломать.
Если собрать указанные типы угроз, получается, что либо сотрудники ИБ не знают, что защищать, либо знают – и для них постоянно меняющееся API становится бесконечным калейдоскопом, разглядеть детали которого уже не представляется возможным.
Мы ещё не закончили: наращивание угрозы
Инвентаризация API не единственная проблема. Есть специфичные угрозы для бизнес-логики, которые следует перечислить:
BOLA (подмена ID): вы меняете свой user_id=10 на 11 в URL. Токен валиден, запрос чист — WAF пропускает. В итоге вы читаете чужие данные, потому что никто не проверил связь между владельцем токена и запрашиваемым объектом.
Mass Assignment: вы добавляете в JSON-запрос поле is_admin: true. Gateway просто пробросит это дальше в базу, и вы получите права администратора «бонусом» к регистрации.
Excessive Data Exposure: API отдает в ответе весь объект профиля, включая технические пароли или хеши, надеясь, что мобильное приложение это просто не покажет. Злоумышленнику достаточно перехватить ответ.
WAAP: Новая надежда
Переход к WAAP (Web Application and API Protection) — это фундаментальный сдвиг от реактивной защиты к проактивной. Он объединяет возможности WAF с глубоким пониманием специфики API:
API Discovery: Автоматическое обнаружение всех эндпоинтов в реальном времени. Система сама строит карту API, выявляя Shadow и Zombie эндпоинты без участия человека.
Positive Security Model: Вместо поиска «плохого», WAAP разрешает только «хорошее». Он импортирует спецификации (Swagger/OpenAPI) и блокирует любые запросы, не соответствующие схеме данных. Это важно, когда, например, вместо строки злоумышленник присылает объекты, тем самым вызывая непредвиденную работу веб-ресурсов. С точки зрения WAF – это практически невозможно отследить
Behavioral Analysis: ML-алгоритмы выявляют аномалии, распознавая ботов или Business Logic Abuse — когда каждый отдельный запрос корректен, но их последовательность говорит о попытке взлома или кражи данных.
Заключение
Нужно честно признаться, WAF – большой инструмент с возможностью писать пользовательские правила, он позволяет смягчать практически все угрозы на прикладном уровне сети, в том числе и связанные с API угрозы. Однако подобное решение не только существенно увеличивает затраты на поддержание безопасности, но и увеличивает нагрузку как на технические средства и персонал.
Чтобы обеспечить реальную безопасность, необходимо признать: защита API — это не фильтрация трафика, а глубокое понимание контекста, состояния сессии и структуры данных, что требует принципиально иного технологического стека, в лице нового класса продуктов WAAP.
