Что изменилось в атаках на API приложений и как сегодня лучше защищаться
Еще несколько лет назад большинство атак на API можно было описать простой цепочкой: злоумышленник находил уязвимость, пытался ее эксплуатировать, а затем получал доступ к данным или нарушал работу сервиса. Поэтому специалисты в первую очередь проверяли ошибки авторизации, нарушения контроля доступа, SQL-инъекции и эксплуатацию известных уязвимостей.
Сегодня эта модель уже не объясняет значительную часть инцидентов. Сервис начинает отвечать медленнее, база данных работает на пределе, пользователи сталкиваются с ошибками при оформлении заказов, а отдельные операции занимают в несколько раз больше времени. При этом WAF не фиксирует опасных запросов, а в журналах отсутствуют признаки взлома.
Причина может заключаться в том, что API используют строго разрешенным способом, но в нетипичном масштабе или по необычному сценарию. Иными словами, приложение делает именно то, что от него требуют штатные методы API. Проблема проявляется не в содержании отдельного запроса, а в совокупном поведении клиента.
Почему корректные запросы становятся угрозой
Через API сегодня работают интернет-магазины, мобильные приложения, личные кабинеты, платежные системы и внутренние сервисы компаний. Внешние партнеры получают доступ к каталогам, ценам, остаткам, статусам заказов и другим данным.
Представим магазин, где документированный API позволяет получать список товаров, сведения о наличии и актуальные цены. Каждый запрос проходит авторизацию, соответствует спецификации и не содержит вредоносных параметров. Однако если несколько автоматизированных систем одновременно начинают обходить десятки тысяч карточек, нагрузка быстро становится критической.
Один из клиентов столкнулся с подобной ситуацией после объявления конкурса на сбор данных из каталога. Несколько подрядчиков почти одновременно запустили инструменты для выгрузки ассортимента, цен и остатков. За короткое время объем обращений вырос почти втрое. Отдельные запросы выглядели нормально, но их совокупность перегрузила инфраструктуру, из-за чего пользователи временно не могли оформить заказ.
Такой сценарий сложно назвать классическим взломом. Злоумышленник не обходит авторизацию и не внедряет код. Он лишь использует доступные функции приложения в объеме, которого система не ожидала.
Почему WAF не всегда помогает
WAF предназначен прежде всего для анализа содержимого HTTP-запросов. Он выявляет сигнатуры SQL-инъекций, XSS, попыток обхода авторизации, эксплуатации известных уязвимостей и других распространенных техник.
Если запрос имеет корректную структуру, содержит допустимые параметры и отправляется авторизованным клиентом, у WAF может не быть оснований его блокировать. Для межсетевого экрана два обращения к одному методу часто выглядят одинаково - даже если одно является обычной операцией пользователя, а второе входит в состав масштабированной автоматизированной атаки.
Поэтому защита API должна учитывать не только тело и заголовки запроса, но и контекст: кто обращается к системе, с какой частотой, к каким методам, в какой последовательности и как меняется его поведение со временем.
Burst-атака: резкая нагрузка на дорогие методы
Один из распространенных сценариев - burst-атака, то есть короткий, но интенсивный всплеск обращений к наиболее ресурсоемким операциям.
Это могут быть:
- поиск по большому объему данных;
- формирование отчетов;
- расчет стоимости доставки;
- проверка доступности товаров на нескольких складах;
- массовая фильтрация каталога;
- операции, вызывающие обращения к нескольким базам или внешним сервисам.
Даже несколько секунд такой активности способны занять пул соединений, увеличить число медленных запросов к базе и вытеснить обычных пользователей. Простое ограничение количества запросов по IP не всегда эффективно: атакующий может распределить нагрузку между множеством адресов, учетных записей или прокси.
Shortwave-атака: короткий запрос в критический момент
Shortwave-атака строится не на длительной нагрузке, а на точном выборе времени. Небольшая серия обращений отправляется в момент, когда система уже занята: во время массовой рекламной кампании, распродажи, публикации важной новости или начала приема заявок.
Каждый отдельный импульс может быть слишком мал, чтобы сработали стандартные пороги. Но он увеличивает задержки и усиливает уже существующую нагрузку. В результате сервис становится нестабильным именно тогда, когда к нему обращается максимальное число легитимных пользователей.
Для обнаружения такого сценария важно учитывать сезонные и событийные нормы. Одинаковое число запросов может быть безопасным днем и опасным в период пикового спроса.
Carpet Bombing: распределенная атака по множеству методов
Еще один вариант - Carpet Bombing, или "ковровая бомбардировка". В этом случае злоумышленник не концентрируется на одном endpoint. Запросы распределяются по десяткам и сотням API-методов.
Каждый метод получает умеренное количество обращений, поэтому локальные лимиты не превышаются. Однако суммарная активность клиента может быть явно нетипичной: он последовательно открывает каталог, проверяет остатки, запрашивает цены, создает черновики заказов и обращается к служебным операциям.
Подобная атака опасна тем, что нагрузка распределяется по разным компонентам инфраструктуры. Один endpoint может нагружать базу, другой - кэш, третий - внешний сервис, а четвертый - очередь фоновых задач. В совокупности это приводит к деградации всей системы.
Почему поведенческий анализ становится обязательным
Современная защита должна отвечать не только на вопрос "опасен ли этот запрос?", но и на более широкий вопрос: "соответствует ли такое поведение нормальному сценарию работы клиента?"
Для этого анализируются:
- частота обращений;
- скорость и последовательность действий;
- количество используемых методов;
- доля ошибок;
- глубина просмотра данных;
- объем выгрузки;
- связь между запросами;
- время активности;
- смена IP-адресов и устройств;
- соответствие поведения типичному профилю пользователя.
Например, человек обычно просматривает несколько товаров, добавляет один или два в корзину и завершает заказ. Автоматизированный сборщик может за короткий период последовательно запросить все страницы каталога, остатки по каждому товару и несколько вариантов сортировки. Каждый шаг разрешен, но общий сценарий заметно отличается от пользовательского.
Как должна выглядеть защита API
Эффективная стратегия начинается с инвентаризации API. Компания должна понимать, какие методы существуют, какие данные они возвращают, кто ими пользуется и какую нагрузку создают отдельные операции.
Следующий уровень - корректная аутентификация и авторизация. Для разных клиентов следует использовать разные учетные данные, минимально необходимые права и отдельные политики доступа. Публичные методы нельзя автоматически считать безопасными: именно они часто становятся источником массового сбора данных и перегрузки.
Не менее важны квоты и ограничения на уровне пользователя, токена, организации, устройства и бизнес-операции. Лимиты должны учитывать стоимость метода. Запрос на получение простой карточки товара и построение сложного отчета не должны иметь одинаковый вес.
Полезно разделять инфраструктуру для критичных и второстепенных операций. Например, массовая выгрузка каталога не должна конкурировать за те же ресурсы, что оформление заказа или проведение платежа. Для тяжелых методов можно применять очереди, асинхронную обработку, кэширование и предварительное формирование результатов.
Что делать при обнаружении аномалии
Автоматическая блокировка - не единственный вариант реакции. В зависимости от уровня риска можно:
- снизить скорость обработки запросов;
- временно ограничить отдельные методы;
- потребовать дополнительную проверку;
- перевести клиента на кэшированные данные;
- сократить объем возвращаемого результата;
- приостановить конкретный токен;
- отправить событие специалистам мониторинга.
Такой подход снижает вероятность блокировки добросовестных клиентов. Например, резкий рост нагрузки у крупного партнера может быть связан с запуском новой функции, а не с атакой. Поведенческая система должна учитывать контекст и постепенно уточнять оценку риска.
Мониторинг и тестирование
Защита API не заканчивается настройкой WAF или лимитов. Необходимо регулярно анализировать задержки, коды ответов, загрузку баз данных, очередей, кэшей и внешних интеграций.
Полезно заранее моделировать сценарии burst, Shortwave и Carpet Bombing в тестовой среде. Это позволяет понять, какие методы становятся узкими местами, насколько быстро исчерпываются соединения и какие лимиты действительно защищают пользователей.
Также следует отслеживать изменения в самом API. Новый endpoint, расширение объема ответа или добавление фильтра может резко увеличить стоимость операции. Каждое изменение должно сопровождаться оценкой рисков, нагрузочным тестированием и обновлением политик мониторинга.
Главный вывод заключается в том, что защита API переходит от простой фильтрации вредоносных запросов к анализу поведения. Угроза может не содержать ни одной инъекции и не нарушать формальные правила доступа. Она возникает тогда, когда разрешенные функции начинают использоваться слишком быстро, слишком массово или в нетипичной последовательности. Поэтому современная система безопасности должна видеть не только отдельный запрос, но и весь сценарий взаимодействия клиента с приложением.