Бизнес-логика API как вектор атаки: уязвимости, которые не может найти сканер безопасности

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

Уязвимости бизнес-логики — это flaws in the way an application implements its intended workflow. Они не связаны с некорректной обработкой входных данных или неэкранированным выводом. Код делает именно то, что сказал разработчик, но то, что сказал разработчик, не совпадает с тем, что на самом деле нужно бизнесу. Пользователь пропускает обязательный шаг, отправляет запрос не в том порядке, платит отрицательную цену или комбинирует купоны так, как никто не планировал.

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

В этой статье мы разберём, как бизнес-логика API становится вектором атаки, какие уязвимости входят в OWASP Business Logic Abuse Top 10 и как эффективно защищать свои API от эксплуатации злоумышленниками.

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

Чем они отличаются от технических уязвимостей

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

Уязвимости бизнес-логики устроены иначе. Они возникают из-за предположений разработчиков: доверие к клиенту, игнорирование пограничных случаев или неправильный порядок проверок. Рассмотрим пример интернет-магазина. Сервер принимает запрос с идентификатором товара, количеством и кодом купона. Каждый параметр валидируется: товар существует, количество — положительное число, купон соответствует известному шаблону. Ни одно техническое правило не нарушено. Но приложение рассчитывает итоговую сумму из переданной клиентом цены вместо того, чтобы получить её с сервера, — и пользователь платит 1 копейку за телевизор. Это уязвимость бизнес-логики, и никакая валидация входных данных здесь не поможет, потому что входные данные синтаксически безупречны.

Почему они так опасны

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

По данным отчёта Salt Security State of API Security (Q1 2023), 84% организаций столкнулись как минимум с одним инцидентом безопасности API за последние 12 месяцев, и многие из них были связаны с эксплуатацией на уровне логики. Согласно IBM Cost of a Data Breach Report (2023), устранение последствий логических атак на API может стоить на 30% дороже, чем устранение традиционных уязвимостей.

Business logic abuse (злоупотребление бизнес-логикой) происходит, когда злоумышленники используют предусмотренную функциональность системы, чтобы заставить её делать то, для чего она не была предназначена. Это технически возможные действия, которые становятся проблемой из-за недочетов в проектировании.

Основные сценарии атак

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

Манипуляция данными. Изменение цены товара в запросе. Именно так работает классический пример с оплатой товара по заниженной цене.

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

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

Перехват сессий, которые не истекли.

Примеры из реального мира

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

Burger King (RBI International). В сентябре 2025 года у сети ресторанов Burger King, Tim Hortons и Popeyes были обнаружены множественные уязвимости API, связанные с работой drive-thru. Злоумышленники могли генерировать токены аутентификации без проверки, получать доступ к аудио с drive-thru и повышать свои привилегии от обычного клиента до администратора.

Instagram API (2026). Утечка затронула 17,5 млн аккаунтов через функцию восстановления пароля. API позволял любому взаимодействовать с чувствительной бизнес-функцией восстановления пароля без достаточного контроля использования этой функции. Даже правильно реализованная функция становится уязвимостью, если бизнес-логика вокруг неё недостаточно контролируется.

Атаки на бизнес-логику в финансовом секторе. По данным Radware, 94% конфигураций реализуют четыре или более элементов атак на бизнес-логику, причём 54% демонстрируют продвинутую оркестрацию, использующую 13+ различных техник.

Большинство традиционных сканеров безопасности ищут известные сигнатуры, паттерны или идентификаторы CVE. Уязвимости логики не следуют этим паттернам — они полностью зависят от контекста.

Ключевые ограничения традиционных инструментов

Отсутствие понимания намерений. Сканеры не могут интерпретировать бизнес-правила или ожидаемые пользовательские потоки.

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

Ложная уверенность. «Чистое» сканирование не означает, что ваша логика безупречна — это означает лишь, что не обнаружено технических ошибок.

Почему в API это особенно актуально

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

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

В 2025 году OWASP опубликовала первый в своём роде OWASP Business Logic Abuse Top 10 — список уязвимостей бизнес-логики, не привязанных к конкретным технологиям. Как отметил Иван Новиков, сооснователь и CEO Wallarm и один из лидеров проекта: «Эти типы атак выходят за рамки конкретного программного стека или технологии. Они не вписываются в существующие таксономии, но активно эксплуатируются злоумышленниками сегодня».

Десять классов уязвимостей бизнес-логики

Класс 1: Lifecycle & Orphaned Transitions Flaws — ошибки в жизненном цикле и «осиротевших» переходах. Объекты или процессы могут переходить в недокументированные или непредусмотренные состояния.

Класс 2: Logic Bomb, Loops and Halting Issues — логические бомбы, циклы и проблемы остановки. API, автоматизирующие бизнес-процессы, могут содержать скрытые триггеры, бесконечные циклы и неограниченную рекурсию, когда в коде отсутствуют проверки завершения или ограничения глубины. Злоумышленники эксплуатируют эти упущения, чтобы многократно запускать скрытые процедуры, исчерпывать CPU и память или вызывать отказ в обслуживании.

Класс 3: Data Type Smuggling — «контрабанда» типов данных. Злоумышленник передает данные одного типа там, где ожидается другой, чтобы обойти проверки.

Класс 4: Sequential State Bypass — обход последовательности состояний. Пользователь пропускает обязательные шаги рабочего процесса.

Класс 5: Data Oracle Exposure — раскрытие данных через «оракул». Система выдаёт разную информацию об ошибках, позволяя злоумышленнику определить, существует ли пользователь или выполнено ли условие.

Класс 6: Missing Roles and Permission Checks — отсутствие проверок ролей и разрешений. Пользователи могут выполнять действия, не соответствующие их роли.

Класс 7: Transition Validation Flaws — ошибки валидации переходов. Система не проверяет, допустим ли переход из одного состояния в другое.

Класс 8: Replays of Idempotency Operations — повторное выполнение идемпотентных операций. Злоумышленник повторяет один и тот же запрос, чтобы получить многократную выгоду.

Класс 9: Race Condition and Concurrency Issues — состояние гонки и проблемы конкурентности. Два запроса выполняются одновременно, и система обрабатывает их в неправильном порядке, что приводит к некорректным результатам.

Класс 10: Resource Quota Violations — нарушение квот ресурсов. Пользователь превышает установленные лимиты.

1. Всегда пересчитывайте критичные для безопасности значения на сервере

Самый эффективный защитный навык: если значение в запросе влияет на безопасность, не доверяйте ему. Цена товара, баланс счёта, роль пользователя, право собственности — всё это должно определяться на сервере, а не приниматься от клиента. Клиентский запрос — это входные данные, а не истина.

2. Внедряйте рабочие процессы как явные конечные автоматы

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

3. Относитесь к конкурентности как к реальной угрозе

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

4. Применяйте rate limiting на уровне функций, а не только аутентификации

Функции, которые особенно привлекательны для злоупотреблений (реферальные программы, купоны, сброс пароля), требуют собственных контролей. Ограничивайте не только количество запросов в секунду, но и количество операций одного типа от одного пользователя (например, максимум 3 применения промокода в день).

5. Моделируйте угрозы на уровне бизнес-процессов

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

6. Выявляйте «теневые» и забытые API

«Теневые» API — это эндпоинты, которых нет в документации, но которые активны в инфраструктуре. Они часто становятся источником уязвимостей. Оптимальный подход — сравнивать задокументированные эндпоинты с реальным трафиком. Если документация ведётся в стандарте OpenAPI (Swagger), валидацию запросов и ответов на соответствие спецификации можно осуществлять в режиме онлайн.

7. Используйте поведенческий анализ и обнаружение аномалий

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

- Понимать нормальное поведение API и пользователей

- Обнаруживать отклонения от этого поведения

- Выявлять необычные последовательности вызовов

8. Проводите тестирование бизнес-логики

Включайте сценарии злоупотребления бизнес-логикой в регулярное тестирование безопасности. OWASP Web Security Testing Guide содержит раздел, посвященный тестированию бизнес-логики. Это требует не автоматических сканеров, а ручного анализа и понимания бизнес-процессов.

9. Внедряйте инвентаризацию и мониторинг API

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

10. Обучайте разработчиков безопасному проектированию

Безопасность бизнес-логики должна закладываться на этапе проектирования. Разработчики должны понимать:

- Что такое уязвимости бизнес-логики и чем они отличаются от технических уязвимостей

- Почему нельзя доверять клиентским данным

- Как проектировать рабочие процессы с учетом возможных злоупотреблений

- Как правильно использовать конечные автоматы и проверки состояния

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

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

Ключевые выводы:

1. Уязвимости бизнес-логики — это не ошибки в коде, а ошибки в проектировании. Код работает именно так, как написан, но делает не то, что нужно бизнесу.

2. Традиционные инструменты безопасности бессильны. WAF и API-шлюзы не понимают бизнес-контекст и не могут отличить легитимное поведение от злоупотребления.

3. OWASP Business Logic Abuse Top 10 — это первый стандартизированный список угроз бизнес-логики, который даёт отрасли общий язык для борьбы с ними.

4. Защита требует смены мышления — от сигнатур и паттернов к поведению и контексту.

5. Безопасность должна закладываться на этапе проектирования, а не добавляться постфактум. Разработчики должны понимать бизнес-процессы и предусматривать сценарии злоупотреблений.

6. Инвентаризация и мониторинг API — основа защиты. Нельзя защитить то, о чём вы не знаете.

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