Атаки на банковские API: как распознать скрытую компрометацию

Атаки на банковские API: как распознать скрытую компрометацию

Среди ключевых: нарушение авторизации на уровне объекта, сломанные механизмы аутентификации, неограниченное потребление ресурсов, нарушение авторизации на уровне функций, неправильная конфигурация, устаревшие endpoint'ы и небезопасное потребление API третьих сторон. Ни одна из этих угроз не предполагает громкого инцидента. Скомпрометированный банковский API внешне продолжает отвечать на запросы — HTTP 200, штатные латентности, типичный payload. Пока атакующий перебирает объекты, крадёт токены или выводит данные через легитимные каналы.

Компрометация не выглядит как пожар. Она выглядит как шум.

Анатомия скрытой компрометации: почему API не подаёт сигналов тревоги

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

Классический сценарий: скомпрометирован OAuth-токен. Клиентское приложение продолжает работать. Пользователь не замечает изменений. API получает запросы с валидным Bearer-токеном, корректной подписью и ожидаемым форматом payload. На уровне API Gateway — всё штатно. Ни одного сбоя аутентификации. Ни одного 401.

Второй сценарий: манипуляция идентификаторами объектов. Атакующий подставляет чужие ID в path-параметры, query string, заголовки или тело запроса. Если сервер не проверяет принадлежность объекта текущему пользователю, злоумышленник получает доступ к чужим данным. OWASP классифицирует это как Broken Object Level Authorization — BOLA. Идентификаторами могут быть последовательные числа, UUID или произвольные строки.

Третий сценарий: компрометация учётных данных через социальную инженерию. Фишинговые рассылки под видом уведомлений о доступном контенте — от банковских обновлений до популярных релизов в цифровом формате — используются для кражи credentials. Дальше — стандартная цепочка: credential stuffing, обход MFA, получение токена. FFIEC указывает, что финансовые организации обязаны учитывать риски скомпрометированных учётных данных, push-платежей и удалённого доступа клиентов.

Скомпрометированный API не падает. Он продолжает отвечать 200 OK — просто уже не тому клиенту.

Индикаторы аномального трафика: что искать в логах и метаданных

Скрытая компрометация проявляется совокупностью отклонений, а не единичным событием. Google Apigee в правилах обнаружения аномалий перечисляет конкретные метрики, которые необходимо мониторить. Любой порог в этих правилах — контекстный: он рассчитывается от исторического профиля конкретного endpoint'а, клиента и временного окна. Универсальных цифр, одинаково применимых к мобильному банку и B2B-интеграции, не существует — каждая организация выстраивает свои допустимые диапазоны по накопленной телеметрии.

Всплески объёма трафика. Резкий рост числа запросов к определённому endpoint'у за короткий интервал. Правило Flooder в Apigee анализирует высокую долю трафика с одного IP-адреса в пятиминутном окне. Отдельный всплеск может быть легитимным (рассылка, кэш-промах). Серийные всплески в одно и то же время суток, с повторяющейся структурой — нет. Важно не абсолютное число запросов, а отклонение от исторического профиля конкретного ресурса с учётом сезонности.

Рост доли ошибок. Высокая доля ответов 4xx и 5xx указывает на перебор параметров, fuzzing или обращение к несуществующим ресурсам. Особенно — массовые 403 Forbidden (отказы в доступе) и 404 (попытки обнаружить скрытые endpoint'ы). Допустимая доля ошибок зависит от endpoint'а: для публичных read-операций она обычно ниже, для write-операций с жёсткой серверной валидацией — выше. Сравнивать нужно с baseline конкретного ресурса, а не с произвольным порогом.

Смена географии и user agent. Один и тот же аккаунт или токен используется из разных регионов, с разных устройств, с отличающимися заголовками User-Agent. Анализ строится на корреляции нескольких атрибутов: IP-подсеть, ASN, fingerprint устройства, TLS-параметры. Один изменившийся атрибут — не инцидент. Резкая смена сразу нескольких в течение одной сессии — повод для проверки.

Аномальный размер запросов и ответов. Непропорционально большой размер ответов может указывать на эксплуатацию эндпоинтов, возвращающих массивные datasets. Слишком маленький размер запросов при большом количестве — на автоматический перебор. Эти аномалии тоже оцениваются относительно профиля конкретного клиента и endpoint'а: одни и те же объёмы для мобильного приложения и сервиса массовых выплат значат разное.

Обращение к нетипичным endpoint'ам. Если клиент исторически работает с /accounts/{id}/balance, а начинает массово обходить /accounts/{id}/transactions, /accounts/{id}/statements, /accounts/{id}/personal-data — это индикатор эскалации. Детектируется на уровне allowlist'а типичных операций для каждой роли или типа клиента: запросы за пределами профиля — алерт, в пределах — норма.

Для анализа рекомендуется сопоставлять события с IP-адресами, API-ключами, URL, user agent и кодами ответов. Минимальный горизонт данных для работы обнаружения аномалий — не менее 2 недель исторических данных о трафике; Google рекомендует 12 недель для повышения точности. При меньшем горизонте модель работает на сырых эвристиках и даёт ложные срабатывания.

Отсутствие записей в логах — не доказательство отсутствия атаки. OWASP прямо относит к признакам недостаточного контроля отсутствие логов, отсутствие непрерывного мониторинга и недостаточную детализацию журналов. Без фиксации неудачных попыток аутентификации, отказов в доступе, ошибок валидации входных данных, попыток обращения к запрещённым функциям и административных действий расследование инцидента становится крайне затруднённым, а в ряде сценариев — невозможным в рамках разумных сроков. Однако итоговая пригодность телеметрии зависит от того, какие события пишутся, с какой детализацией и как долго хранятся — формальное наличие SIEM не гарантирует релевантности данных.

Манипуляции с объектами и авторизацией: выявление Broken Object Level Authorization

BOLA — наиболее частая категория в OWASP API Security Top 10. Суть: клиент запрашивает объект по идентификатору, сервер не проверяет, принадлежит ли объект данному пользователю. В банковском контексте это прямой путь к чужим счетам, транзакциям, персональным данным.

Механика атаки:

1. Перехват легитимного запроса. Клиент обращается к /api/v2/accounts/1042/transactions. Идентификатор 1042 — числовой, последовательный.

2. Подстановка идентификатора. Атакующий заменяет 1042 на 1043, 1044, 1045 — перебор в цикле. UUID сложнее перебрать, но не защищает, если авторизация не проверяется.

3. Проверка ответа. Если сервер возвращает данные чужого аккаунта — объект не защищён. Если 403 — авторизация на уровне объекта работает.

Проблема в том, что массовый перебор числовых ID выглядит как серия штатных запросов. Нет SQL-инъекции, нет эксплойта. Каждый отдельный запрос — валидный HTTP GET с валидным токеном. Обнаружение требует корреляции: один клиент, один токен, диапазон последовательных идентификаторов за короткий интервал. Если endpoint'ы выдают данные последовательно и без пагинации, атакующий может извлечь всё содержимое за один прогон — особенно опасно в API выписок и истории операций.

К OWASP-индикаторам манипуляции идентификаторами относятся обращения к объектам за пределами типичного набора клиента. Если мобильный банк исторически запрашивает данные 2–3 аккаунтов, а начинает перебирать сотни — это детектируется на уровне корреляции. Дополнительный признак — резкий рост числа уникальных идентификаторов в логах при стабильном числе активных клиентов: один и тот же пользователь физически не может запрашивать тысячи чужих аккаунтов в рамках легитимного сценария.

Дополнительный вектор — эскалация привилегий через функции. Нарушение авторизации на уровне функций: клиент с правами на чтение баланса обращается к endpoint'у перевода средств. Ролевая модель API должна быть жёсткой. Если роль клиента определяется на стороне фронтенда, а бэкенд доверяет параметру из запроса — эскалация тривиальна. OWASP отдельно выделяет массовое назначение прав (Mass Assignment), когда клиент через payload пытается повысить собственные привилегии: например, передаёт поле is_admin: true в регистрационных данных или меняет роль в PUT-запросе.

BOLA эксплуатирует архитектурное допущение: сервер верит, что клиент запрашивает только свой объект. Это допущение ложно.

Стратегии защиты: от sender-constrained токенов до централизованного логирования

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

Аутентификация. NIST SP 800-63B-4 определяет для уровня AAL2 обязательное использование двух различных факторов или многофакторного аутентификатора с одобренной криптографией. Провайдер должен предоставить как минимум один вариант аутентификации, устойчивый к фишингу. Ручной ввод одноразового пароля — SMS-OTP или TOTP — к таким вариантам не относится. Злоумышленник перехватывает и ретранслирует код в реальном времени. К phishing-resistant относятся криптографические методы с привязкой к каналу или имени проверяющей стороны — аппаратные ключи FIDO2, сертификаты mTLS.

Рекомендуемый общий срок до повторной аутентификации для AAL2 — не более 24 часов. Тайм-аут бездействия — не более 1 часа. Для AAL3 — 12 часов и 15 минут соответственно. Сокращение сроков снижает окно для повторного использования украденной сессии, но должно балансироваться с удобством пользователя и продуктовой моделью — жёсткие лимиты ради безопасности часто проигрывают удобству и обходятся клиентами.

OAuth 2.0 и токены. RFC 9700, опубликованный IETF в январе 2025 года, предусматривает защиту от повторного использования украденных access token с помощью sender-constrained tokens. Два механизма: mTLS (привязка токена к сертификату клиента) и DPoP (Demonstration of Proof-of-Possession, привязка к ключу на уровне приложения). Без sender-constraining украденный Bearer-токен работает из любого контекста — атакующему достаточно перенести заголовок Authorization в свой запрос.

Рекомендации RFC 9700 включают end-to-end TLS для всех OAuth-взаимодействий и аутентификацию клиента с использованием асимметричной криптографии. PKCE обязателен для authorization code flow. По структуре токенов спецификация указывает, что токены не должны раскрывать избыточную информацию о клиенте или внутренней системе, а при использовании структурированных форматов вроде JWT необходимо учитывать риск утечки атрибутов и компенсировать их sender-constraining, коротким сроком жизни и минимизацией claims. Универсального запрета на JWT в RFC 9700 нет — решение принимается исходя из реализации, чувствительности payload и наличия компенсирующих контролей.

Контроль жизненного цикла токенов. Срок действия access token должен быть минимально необходимым. Refresh token — с механизмом ротации: при каждом использовании выдаётся новый, старый инвалидируется. Скомпрометированный refresh token без ротации даёт неограниченный доступ. Дополнительно — связывание refresh token с device fingerprint и client_id: запрос на ротацию из аномального контекста должен отклоняться. Без ротации refresh token становится долгосрочным ключом ко всему API.

Авторизация. Проверка на уровне каждого объекта, каждого поля, каждого действия. Никаких последовательных числовых идентификаторов без дополнительного контроля — UUID или составные идентификаторы снижают эффект перебора, но не заменяют авторизационную проверку. Ролевая модель — на стороне API, не на стороне клиента. Права — минимальные, принцип наименьших привилегий. На каждый endpoint — отдельная матрица прав с проверкой на сервере, без предположений о том, что клиент "не станет так делать".

Логирование и мониторинг. OWASP рекомендует фиксировать как минимум:

• неудачные попытки аутентификации;
• отказы в доступе (403, 401);
• ошибки валидации входных данных;
• попытки обращения к запрещённым функциям;
• административные действия;
• изменения настроек безопасности.

Логи API должны агрегироваться в централизованной системе. Это может быть собственный SIEM, облачный log management-сервис или выделенное хранилище с ретенцией, достаточной для расследования. Главное — вывести события за пределы скомпрометированного периметра: локальные логи на том же хосте, что и атакованный сервис, атакующий способен модифицировать или удалить. CISA рекомендует использовать централизованный сервер, шифрование передачи и неизменяемые журналы с периодом хранения, достаточным для расследования инцидента. Выбор между собственным SIEM и аутсорсингом зависит от зрелости команды, требований регулятора и объёма телеметрии — формального требования "только свой SIEM" нет, есть требование централизации и сохранности.

Apigee для анализа инцидентов предоставляет Raw data — выборку до 1000 строк по каждому событию. Этого достаточно для первичной триажи, но недостаточно для полноценного расследования атаки с масштабным перебором: 1000 строк на событие покрывают несколько минут трафика, тогда как скрытая компрометация может разворачиваться неделями. Если собственной телеметрии не хватает, подключают долгосрочное хранилище (data lake, SIEM) и SIEM-правила поверх него. Отсутствие такого слоя не обнуляет защиту в реальном времени, но резко сужает окно ретроспективного анализа.

Регламенты мониторинга: как отличить штатную нагрузку от целенаправленной атаки

Любой индикатор из перечисленных может быть легитимным. Всплеск трафика — маркетинговая рассылка. Рост 4xx — обновление клиентского приложения. Смена географии — пользователь в поездке. Множественные OAuth-сессии — семейный аккаунт или B2B-интеграция с несколькими операторами. Поэтому детектирование скрытой компрометации — задача корреляции, а не единичного правила.

Baseline. Построение нормального профиля трафика для каждого endpoint'а, каждого клиента, каждого временного окна. Google рекомендует минимум 12 недель данных. Baseline включает: типичный объём запросов, распределение по методам, стандартный набор endpoint'ов, географический профиль, спектр user agent. Без baseline любой порог — произвольный, и его калибровка требует данных о реальной нагрузке. Организации без зрелого baseline склонны либо занижать пороги и тонуть в алертах, либо завышать их и пропускать атаки.

Корреляция событий. Единичный индикатор — noise. Совокупность — сигнал. Пример: один клиент, одна IP-подсеть, серия GET-запросов к /accounts/{id} с перебором ID, коды 200 на чужие объекты, отсутствие типичных POST-операций. Ни один из признаков в отдельности не доказывает атаку. Совокупность — повод для блокировки и расследования. Корреляция может строиться по временному окну (5–15 минут), по сессии (один токен или fingerprint) или по IP-подсети. Чем больше ортогональных признаков сходятся, тем выше уверенность.

Детерминированные правила. Помимо статистического обнаружения аномалий, нужны жёсткие правила:

• N неудачных аутентификаций за интервал → блокировка + алерт.
• Обращение к endpoint'у, не входящему в allowlist для данного типа клиента → отказ + лог.
• Превышение rate limit → throttle + уведомление.
• Access token используется без привязки к expected client certificate (при mTLS) → отзыв токена.

Каждое из этих правил требует калибровки: N зависит от endpoint'а и сценария, allowlist — от роли, rate limit — от продукта. Универсальные значения приводят либо к шуму, либо к пропуску инцидентов.

Управление клиентскими интеграциями. FFIEC выделяет отдельные риски для data aggregators и customer-permissioned entities. Доступ может быть credential-based (клиент передаёт логин и пароль агрегатору) или API/token-based (прямой доступ по OAuth). Каждая модель требует отдельной оценки рисков и компенсирующих контролей. Credential-based модель — устаревшая и рискованная: агрегатор хранит учётные данные клиента, появляется общая точка компрометации. API/token-based с ограниченными scope и sender-constraining — минимально приемлемый вариант, но и он требует мониторинга: агрегатор скомпрометирован → массовая утечка через легитимные токены.

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

Скрытая компрометация дороже явной. Явную находят быстро. Скрытая работает неделями и месяцами, извлекая данные через легитимные каналы. Обнаружить её можно только системой, которая знает свой baseline, коррелирует события и логирует всё, что отклоняется от нормы. Без этих трёх элементов банк видит только легитимный трафик — и продолжает выдавать 200 OK тому, кто уже работает не на его клиента.