Как защищать API в условиях роста атак: инвентаризация, бизнес-логика и автоматизация

Рост количества цифровых сервисов делает API одним из наиболее ценных и уязвимых компонентов современной инфраструктуры. По мере перехода к микросервисам, облачным платформам и API-first подходам расширяется поверхность атак, усложняется инвентаризация сервисов и возрастает роль автоматизации защиты. Ошибки в бизнес-логике, рассогласование спецификаций, «теневые» эндпойнты и злоупотребления внутренними API — всё это приводит к утечкам данных, нарушениям авторизации и новым сценариям атак.

Редакция CISOCLUB пообщалась с Павлом Нагиным, руководителем по развитию продуктов SQUAD, чтобы разобраться, как находить забытые и недокументированные API, какие уязвимости встречаются чаще всего, когда допустим «виртуальный патчинг», какие архитектурные меры помогают в микросервисной среде, как синхронизировать Swagger/OpenAPI со сменой логики, применять модели аномалий без всплесков ложных срабатываний и почему в ближайшие годы роль AI в защите API будет только расти.

Как выявлять «теневые» или забытые API, которые не задокументированы, но остаются активными в инфраструктуре?

Выявление «теневых» и забытых API нужно начинать со сравнения того, что задокументировано и того, что мы видим в реальном трафике. Оптимально, если документирование ведется в стандарте OpenAPI (Swagger) спецификации, тогда валидацию запросов и ответов на соответствие спецификации можно осуществлять в онлайн режиме. При этом под категорию «теневых» попадут все эндпойнты, которых нет в описании, а забытыми будем считать те эндпойнты, которые есть в описании, но к ним не было обращений в течение длительного периода времени. Если описания нет, то его можно составить автоматически по запросам и ответам к API, далее такое описание нужно валидировать с помощью документации и/или разработчиков сервиса, и уже после делать онлайн валидацию, выявляя новые эндпойнты, методы и параметры. Дополнительную помощь могут оказать сигнатуры, выявляющие мониторинговые и административные API, которые не должны быть доступны для всех. Как правило их публикуют только во внутренней сети организации. Пример того, как публикация мониторинговых API в сети Интернет приводит к раскрытию данных, атакам отказа обслуживания и даже удаленному выполнению кода.

Где чаще всего кроются уязвимости в API по части бизнес-логики, и как их предотвращать?

Согласно списку угроз некоммерческой организации OWASP, первые три места по критичности занимают атаки, связанные с аутентификацией и авторизацией:

• API1:2023 — Broken Object Level Authorization
• API2:2023 — Broken Authentication
• API3:2023 — Broken Object Property Level Authorization

Примеры из жизни подтверждают актуальность данных угроз. Например, часто разработчики забывают добавить проверку при доступе пользователей к чужим данным, и тогда один пользователь может получить персональную или финансовую информацию других пользователей. Иногда разработчики вообще забывают про аутентификацию и это приводит к крупным утечкам. Одним из реальных примеров — в API для мобильного приложения «Росреестра» можно было без аутентификации и авторизации получать персональные данные (ПД) владельцев недвижимости.

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

Насколько эффективен подход «виртуального патчинга» API на уровне прокси по сравнению с исправлением кода?

«Витруальный патчинг» спасает в ситуациях, когда нет возможности быстро исправить уязвимость в API и в то же время нужно обеспечить доступность сервиса. Патчинг на уровне прокси помогает остановить «плохие» запросы до того, как они попадут в уязвимое приложение. При этом надо понимать, что данная мера не является полноценной защитой, так как могут быть найдены способы обойти проверку, также в какой-то момент «виртуальный патч» или средство защиты могут перестать работать. Поэтому только исправление уязвимости в самом API может гарантировать его безопасность.

Какие архитектурные меры наиболее полезны для API-защиты при микросервисной структуре?

При использовании микросервисной структуры быстро растет количество и разнообразие API-сервисов, поэтому критичную роль играет инвентаризация – невозможно защитить то, что ты не знаешь. Описание API необходимо формировать на этапе разработки и поддерживать его актуальность на этапах развития и эксплуатации. Также при проектировании микросервисов важно учитывать такие функции, как аутентификация, авторизация и шифрование данных при передаче. Крупные компании как правило формируют единый подход к этим функциям и чаще всего реализуют их централизованно на API-шлюзах. Дополнительными мерами защиты могут быть лимиты по количеству обращений и блокировка по сигнатурам известных атак. Все эти меры работают в микросервисах комплексно и эффективно, особенно, если стандартизированы на уровне архитектуры.

Как синхронизировать спецификации (Swagger / OpenAPI) с реальным поведением API, чтобы не было рассогласований?

В данной ситуации может помочь автоматическое построение swagger-схем на основании запросов и ответов в рамках работы API. Есть как коммерческие, так и открытые инструменты, которые помогают с реализацией.

Обработка рассогласований зависит от подходов к CI/CD, принятых в организации, но все признают, что требуется максимальная автоматизация данного процесса. Примером успешной реализации может быть работа через GIT:

• Разработчик через Pull Request (PR) публикует в git-репозитории актуальную swagger-схему нового или измененного API-сервиса.
• Схему валидирует другой разрабочик и/или appsec, после этого происходит merge в основную ветку репозитория, откуда она автоматически применяется на API-шлюзе.
• Запускается деплой нового или измененного API-сервиса.

Если API-шлюз выявляет несоответствие запроса или ответа swagger-схеме, происходит автоматическое информирование всех заинтересованных. В зависимости от политики компании такие запросы или ответы могут блокироваться до обновления swagger-схемы разработчиком.

Какие угрозы связаны с внедрением API-first подхода, когда даже внутренние сервисы активно экспонируются?

API-first подход предполагает ключевую роль API при разработке сервисов. Плюсом является то, что сервисы описываются до программной реализации и часть рисков можно минимизировать на данном этапе. Минусы тоже есть – описание часто теряет актуальность, сервисы разрабатываются очень быстро и не всегда есть время сделать комплексную оценку безопасности. В такой ситуации митигация рисков смещается в сторону эксплуатации (shift right), поэтому важен комплексный подход к реагированию на угрозы. В первую очередь стоить ориентироваться на список от OWASP, который помогает расставить приоритеты:

OWASP Top 10 API Security Risks – 2023

Как применять модели обнаружения аномалий для API-трафика, чтобы не было много ложных срабатываний?

Лучше всего работают модели с простой и понятной логикой. Например, 100% рост количества запросов к эндпойнту аутентификации по отношению к предыдущему периоду времени (минута, час, …) однозначно говорит об аномалии, хотя и не всегда она связана с атакой. Если логика более сложная, то лучше использовать дополнительные механизмы для подавления ложных срабатываний. С такими задачами неплохо справляются современные модели искусственного интеллекта на основе больших языковых моделей (LLM).

Какие сложности появляются при защите API в гибридных средах с облаками и локальными системами?

Облачные среды как правило предлагают ограниченный набор сервисов и четкие правила для деплоя приложений. Соответственно, системы защиты API должны работать с учетом этих ограничений. В локальных системах наоборот — больше гибкости, но многие вспомогательные сервисы (git, kafka, prometheus, …) придется разворачивать и настраивать самостоятельно. Хорошая система защиты API должна поддерживать несколько вариантов развертывания, чтобы удовлетворить потребности разных клиентов.

Как реагировать на новые векторы атак, такие как API chaining или abusing API для внутренних систем?

API chaining предполагает последовательное обращение к различным энпойнтам, при этом данные, которые возвращает один эндпойнт, используются в обращении к следующему. Злоумышленники часто игнорируют такие последовательности и пытаются работать с интересующим их эндпойнтом, подбирая нужные данные или не отсылая их вовсе. Это позволяет хакерам находить уязвимости в бизнес логике и ускорять саму атаку в целом. Система защиты API может запоминать очередность вызова API и автоматически выявлять нарушение последовательности, например, после n запросов, когда все предыдущие не нарушали последовательность. Отдельно должна быть возможность настраивать свои последовательности и алерты/блокировки при их нарушении. Также полезно определять таймауты, например, после двух минут бездействия не считать следующий вызов API последовательностью. Отслеживание параметров, которые используются из предыдущего вызова, поможет детектировать IDORы. Например, пользователь получил список идентификаторов своих покупок, но следующим запросов пытается получить покупку по идентификатору не из списка.

API abusing – общий класс атак, в которых эксплуатируют уязвимости в прикладной части или в бизнес-логике. Поэтому реагирование и предотвращение предполагает комплекс мер, таких как:

• регулярное тестирование на безопасность
• лимиты на количество запросов
• строгая аутентификация и авторизация
• постоянная инвентаризация и мониторинг атак

Как вы видите развитие рынка защиты API в ближайшие 2–3 года: больше облачных платформ, автоматизация, модели поведения?

Резкий рост количества и разнообразия API приведет к росту успешных атак, и как следствие вырастет потребность в комплексной и современной защите, которая должна будет поддерживать современные облачные системы, хорошо интегрироваться с API-шлюзами и другими корпоративными системами, а также использовать разнообразные механизмы выявления и предотвращения атак. Облачные провайдеры будут добавлять эти функции через приобретение специализированных решений (Akamai приобрела Noname за 450 млн. долл.) или через создание и развитие собственной экспертизы (Yandex Smart Web Security). Очевидным является тренд на использование искусственного интеллекта, который с одной стороны позволяет повысить точность детектирования, упростить настройку и реагирование в системах защиты API, с другой стороны он потребует от самих систем защиты выявлять и предотвращать атаки на искусственный интеллект.