Защита API от бот-атак и злоупотребления бизнес-логикой

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

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

По данным Akamai и Traceable, на API уже приходится от 57 до 70% веб-трафика. За 2023–2024 годы было зафиксировано более 100 млрд атак на API. При этом лишь 10-15% компаний способны эффективно выявлять и блокировать подобные угрозы.

Многие современные атаки не выглядят как атаки в привычном понимании. Запросы корректны, токены действительны, структура данных соответствует спецификации API. Однако если посмотреть на последовательность действий, распределение запросов или цель взаимодействия с сервисом, становится очевидно, что речь идёт злоупотреблении бизнес-логикой приложения.

Именно поэтому разговор о защите API сегодня выходит далеко за рамки поиска известных уязвимостей.

Не все атаки на API связаны с эксплуатацией уязвимостей

Большинство специалистов по безопасности хорошо знакомы с рисками, описанными в OWASP API Security Top 10. Речь идёт об ошибках авторизации и аутентификации, проблемах контроля доступа, неправильной конфигурации, SSRF, инъекциях и других уязвимостях, которые позволяют злоумышленнику нарушить предусмотренную логику работы приложения.

Для многих таких сценариев существуют хорошо отработанные механизмы защиты: сигнатурный анализ (WAF), контроль запросов и другие инструменты эффективно выявляют попытки эксплуатации известных классов уязвимостей.

Однако на практике всё чаще встречаются атаки другого типа.

С одной стороны, это попытки исчерпания ресурсов приложения – Unrestricted Resource Consumption. С другой – злоупотребление бизнес-логикой, или Business Logic Abuse. В обоих случаях злоумышленник может использовать совершенно легитимные методы API, не нарушая формат запросов и не пытаясь эксплуатировать конкретную уязвимость.

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

Рассмотрим несколько примеров.

Burst: когда систему ломают нагрузкой

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

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

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

Особенность burst-атак заключается в их кратковременности. Многие системы мониторинга и анализа просто не успевают отреагировать на столь короткий всплеск активности. Атака может закончиться раньше, чем будут рассчитаны необходимые метрики или сработают правила автоматического реагирования.

В качестве меры митигации в таких ситуациях часто прибегают к rate limiting – ограничению количества запросов, которые пользователь или система могут отправить за определенный промежуток времени. Однако здесь возникает известный компромисс между безопасностью и доступностью. Если ограничения слишком мягкие, они не помогают остановить атаку. Если слишком жёсткие – начинают затрагивать реальных пользователей. Поэтому всё чаще используются механизмы скользящих окон (Sliding Window). В отличие от фиксированных временных интервалов, такой подход оценивает активность в непрерывном временном окне и позволяет точнее реагировать на короткие всплески нагрузки без избыточных ограничений для легитимных пользователей.

Однако даже грамотно настроенные лимиты не решают всех проблем.

Shortwave: когда атаку строят вокруг времени

Если burst воздействует на систему количеством запросов, то shortwave использует другой подход – время. Такая атака представляет собой серию коротких импульсов с паузами между ними. Средний объём трафика может оставаться вполне обычным и не вызывать подозрений. Более того, злоумышленник специально подбирает интервалы между сериями запросов так, чтобы не превышать настроенные лимиты по числу обращений. В результате отдельные всплески активности могут оставаться ниже пороговых значений, хотя их частота и последовательность позволяют добиться нужного эффекта — например, создать повышенную нагрузку на отдельную функцию приложения или спровоцировать состояние гонки (race condition), когда приложение начинает параллельно обрабатывать несколько запросов, но ещё не успело корректно обновить общее состояние системы.

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

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

«Ковровые бомбардировки»: когда запросы распределяются по широкому набору API-эндпоинтов

В отличие от burst при «ковровых бомбардировках» (carpet bombing) нет одного проблемного эндпоинта. В отличие от shortwave нет необходимости попадать в конкретное состояние приложения. Активность распределяется по большому количеству API-методов, параметров и пользовательских сценариев.

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

Почему одного WAF недостаточно

На этом этапе обычно возникает вопрос: если существуют WAF и другие средства защиты приложений, почему они не решают описанные проблемы?

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

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

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

Экономические последствия атак на API

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

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

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

Существуют и более прямые способы нанесения ущерба. Например, перебор промокодов, массовая отправка авторизационных SMS или интенсивное использование платных API-интерфейсов, за обращение к которым компания платит сторонним поставщикам.

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

Почему защита API всё больше зависит от поведенческого анализа

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

Только такой подход позволяет выявлять автоматизированные сценарии, которые остаются незаметными на уровне отдельных запросов.

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

Эшелонированная защита API

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

• Первый уровень – периметральная защита. CDN, WAF и средства защиты от DDoS помогают блокировать известные угрозы и снижать нагрузку на инфраструктуру.
• Второй уровень – контроль трафика. Rate limiting, квоты и механизмы скользящих окон позволяют ограничивать влияние всплесков активности и защищать ресурсоёмкие операции.
• Третий уровень – поведенческий анализ. Именно он помогает обнаруживать автоматизированные сценарии, которые невозможно выявить по содержимому отдельных запросов.
• Четвёртый уровень – защита приложения. Здесь критически важны идемпотентность операций, атомарные транзакции и корректный контроль конкурентного доступа к данным.
• Пятый уровень – защита бизнес-логики. На этом уровне учитывается специфика самого сервиса: допустимое количество операций, особенности пользовательских сценариев, работа с ограниченными ресурсами и другие аспекты, которые невозможно описать универсальными правилами.

Как сегодня обеспечить эффективную защиту API от ботов

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

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

Автор: Илья Кочарян, инженер команды сопровождения сервисов ИБ NGENIX