Что изменилось в атаках на API приложений и как сегодня лучше защищаться

Еще несколько лет назад большинство инцидентов вокруг API выглядело довольно предсказуемо. Если приложение начинало вести себя подозрительно, специалисты искали ошибки авторизации, проблемы контроля доступа, признаки SQL-инъекций или попытки эксплуатации известных уязвимостей. Логика была простой: есть уязвимость => есть эксплуатация => есть последствия.

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

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

Хороший пример — автоматизированный сбор данных через API. Представим себе интернет-магазин. Через API доступны каталог товаров, остатки на складах и цены. Все методы документированы, авторизация проходит корректно, запросы соответствуют спецификации. На уровне отдельного обращения никакой проблемы нет. Но если несколько автоматизированных систем одновременно начинают регулярно обходить десятки тысяч карточек товаров, ситуация быстро меняется.

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

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

Почему WAF может не защитить от атак на API

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

Здесь возникает закономерный вопрос: почему подобную активность не блокирует межсетевой экран для приложений (WAF)? Потому что WAF решает другую задачу: он анализирует содержимое каждого запроса и ищет признаки известных техник атаки: инъекции, обход авторизации, попытки эксплуатации уязвимостей и другие сигнатуры. Если запрос соответствует спецификации API и не содержит признаков вредоносного воздействия, причин для его блокировки нет.

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

Burst-атака: перегрузка наиболее ресурсоемких API-методов

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

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

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

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

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

Shortwave-атака: короткий запрос в нужный момент

Если Burst пытается создать проблемы за счет стоимости обработки запросов, то при Shortwave злоумышленника интересует не количество запросов, а момент их выполнения. Внешне такая активность выглядит довольно безобидно. Вместо непрерывного потока обращений система получает короткие импульсы запросов, между которыми выдерживаются паузы. Средний объем трафика остается в пределах нормы, лимиты не превышаются, то есть никаких явных признаков атаки не возникает.

Именно поэтому подобные сценарии часто проходят мимо систем мониторинга. Основная цель здесь — добиться определенного состояния приложения. Чаще всего речь идет о так называемом race condition, или состоянии гонки. Это ситуация, когда несколько запросов одновременно обращаются к одной операции, а приложение не успевает корректно обновить общее состояние системы. На практике такие проблемы обычно проявляются не в инфраструктуре, а в бизнес-логике.

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

1. Система проверяет, использовался ли промокод ранее.

2. Если нет, применяет скидку.

3. Отмечает промокод как использованный.

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

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

Это атака типа race condition («гонка запросов»), а в платёжном контексте — попытка повторной обработки операции или double spending / double charge.

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

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

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

Carpet Bombing: удары по десяткам и сотням API-методов

Если Burst концентрируется на одной функции, а Shortwave пытается попасть в определенное состояние приложения, то следующий сценарий действует еще менее заметно. Речь идет о так называемых ковровых атаках или Carpet Bombing.

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

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

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

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

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

По нашим наблюдениям, на сайтах бронирования авиабилетов до 45% всего трафика может приходиться на автоматизированные системы, причем значительная часть такой активности является нежелательной.

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

При этом формально API работал корректно. Система просто использовалась способом, который разработчики не закладывали в свои сценарии. Именно здесь становится заметно главное ограничение традиционных подходов к защите.

Если WAF отвечает на вопрос "опасен ли этот запрос?", то современные атаки на API требуют ответа на совершенно другой вопрос: "Зачем пользователь выполняет эти действия и насколько его поведение похоже на поведение реального пользователя?"

Именно поэтому защита API все чаще смещается из области анализа запросов в область анализа поведения.

Почему поведенческий анализ становится обязательным для защиты API

Когда специалисты впервые сталкиваются с подобными сценариями, возникает соблазн решить проблему привычными средствами: добавить новые сигнатуры, ужесточить лимиты, заблокировать подозрительные IP-адреса. Иногда это действительно помогает.

Но только до тех пор, пока злоумышленник не меняет тактику. На практике поведенческий анализ начинается с довольно простого вопроса: насколько наблюдаемая активность похожа на поведение реального пользователя? Проблема в том, что ответ далеко не всегда очевиден. Допустим, мы видим пользователя, который авторизуется в системе, обновляет токен доступа, выполняет поиск, открывает карточки товаров и проверяет наличие на складе. Сам по себе такой сценарий выглядит абсолютно нормальным. Но если посмотреть на него в контексте нескольких часов или дней, картина может измениться.

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

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

Иногда такие расследования приводят к неожиданным результатам. В одном из проектов клиент долгое время считал источник повышенной нагрузки партнерской интеграцией. Активность выглядела легитимной. Использовались корректные методы API. Запросы приходили регулярно и не содержали признаков вредоносного воздействия. Только после детального анализа выяснилось, что речь идет о системе автоматизированного парсинга цен.

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

Как выглядит защита API приложения сегодня

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

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

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

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

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

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

От простой фильтрации к пониманию поведения

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

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

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