Почему защищённый API — это новый чёрный. Рекомендации по устранению актуальных угроз API

Почему защищённый API — это новый чёрный. Рекомендации по устранению актуальных угроз API

О современной роли API

Дословно API (Application Programming Interface) — это программный интерфейс приложения. Он описывает, как именно программы могут передавать друг другу данные и функции.

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

Как безопасность API стала проблемой бизнеса

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

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

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

Что угрожает API в 2023 году

Инженеры-аналитики Servicepipe фиксируют, что до 20% трафика в адрес API наших клиентов поступает из нелегитимных источников.

Часть угроз — традиционно из эталонного списка OWASP API Security Top 10, базовой отправной точки усиления безопасности API.

Другая часть — это и относительно новые угрозы (Zombie/Shadow API, SMS Leak), и наши старые знакомые (DDoS и ATO-атаки).

Zombie API. Так называют неактуальный API, которые вследствие отсутствия регулярных обновлений становится легкоуязвимым объектом атаки.

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

SMS Leak. Один из популярных видов API-абуза (злоупотребления). Атака на бизнес-логику веб-ресурса, эксплуатирующая функционал автоматизированной отправки SMS с целью исчерпания баланса у SMS-агрегатора [1].

DDoS-атаки. Переполнение сервера многочисленными запросами к API до отказа в обслуживании.

ATO-атаки. Автоматизированный захват аккаунта (Account takeover) с помощью подстановки украденных учётных данных (Credential stuffing) реальных пользователей. По-прежнему в топе головных болей кибербезопасников во многом из-за того, что угрожает любому сайту/приложению, имеющему страницу авторизации с помощью логина/пароля. 

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

Как защищать API в 2023 году

Привычные средства защиты — это анализ логов, API-шлюз и WAF.

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

Сегодня продвинутые боты могут практически полностью имитировать пользовательское взаимодействие. Для этого они используют корректные запросы, ключи API и украденные учётные данные пользователей.

Разработчики не могут предусмотреть все возможные пробелы бизнес-логики в своих API, а инструменты их предварительного тестирования не могут выявить все недоработки.

С подобными атаками мы в Servicepipe сталкиваемся каждый день. Для борьбы с любой нелегитимной автоматизацией (в том числе в сторону API) мы разработали и развиваем собственную антибот-технологию Cybert (рис. 1). 

Рисунок 1. Ботовые запросы к API на фоне легитимной суточной активности

Рассмотрим пару кейсов отражения подобных атак.

Защита API финансовых приложений

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

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

Решение Servicepipe. Мы предложили защитить API финансовых приложений без раскрытия приватного ключа SSL с помощью Cybert.

Схема защиты API. Антибот разворачивается по гибридной схеме в виде NGINX-модуля внутри инфраструктуры клиента. Сервер с установленным SSL-сертификатом принимает соединение и устанавливает HTTPS-сессию. Развёрнутый на нём NGINX-модуль получает необходимые для анализа на прикладном уровне метаданные запроса к API и при необходимости направляет их на проверку в сеть Servicepipe. Получив в ответ вердикт в HTTP-заголовке, модуль выдаёт серверу директиву пропустить или заблокировать данный запрос (рис. 2).

Рисунок 2. Гибридная схема защиты API с помощью NGINX-модуля Servicepipe в инфраструктуре клиента

Результат. Для API нескольких финансовых мобильных приложений была развёрнута защита от ботов и DDoS по схеме без раскрытия SSL. Антибот проанализировал метаданные и за 3 дня обучился трафику защищаемых мобильных приложений.

Вредоносные боты стали блокироваться с первого API-запроса в реальном времени. Анализ логов больше не требовался.

Защита API интернет-магазина

Ситуация и задача. Интернет-магазин испытывал проблему с атаками на бизнес-логику. Продвинутые боты, имитируя действия пользователей, добавляли товары в корзину. Товары резервировались на определённое время. Тем самым ботнет парализовывал работу интернет-магазина, поскольку товары оказывались недоступны для реальных пользователей.

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

Текущие средства защиты от DDoS не могли определить паттерн атаки, поскольку активность шла с разных IP-адресов.

Решение. Компания обратилась к нам за помощью, в результате чего антибот Servicepipe Cybert начал выявлять и блокировать вредоносные запросы сразу после подключения. Время на обучение системы защиты не требовалось, так как трафик был исключительно браузерный. Любые попытки использовать фулстек-ботов для атак на API также блокировались. 

Результат. Нам удалось восстановить логистику и работу интернет-магазина практически сразу после обращения заказчика с проблемой.

Рекомендации по защите API от Servicepipe

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

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

[1] Об этой весьма разорительной атаке читайте в BIS Journal № 2/2023: Д. Чежин, «Защищая пользователей, защищайтесь сами».