Логические уязвимости (Logic Flaws): полный разбор, примеры атак и практические методы защиты

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

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

Что такое логические уязвимости?

Логическая уязвимость — это ошибка, возникающая из-за некорректной логики процесса, неправильного проектирования или неверных допущений разработчиков. В отличие от технических уязвимостей (SQL-инъекций, XSS, переполнения буфера), логические баги не зависят от конкретной строки кода. Они связаны с тем, как работает система в целом.

Система работает корректно с точки зрения программиста, но неверно с точки зрения безопасности.

Примеры таких ситуаций:

• клиент контролирует цену товара;
• пользователь может изменить ID объекта и получить доступ к чужой записи (IDOR);
• можно пропустить этап проверки личности;
• можно получить бонус несколько раз, если отправить запросы одновременно;
• можно завершить действие, даже если предыдущий шаг не выполнен;
• логика API допускает некорректный порядок запросов.

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

Почему логические уязвимости так опасны?

Логические уязвимости обладают рядом особенностей, которые делают их критическими:

• автоматические сканеры их не видят — такие баги могут обнаружить только люди;
• иногда обнаруживаются после многих лет эксплуатации системы;
• могут приводить к огромным финансовым потерям (например, возможность изменить цену товара);
• позволяют обходить контроль доступа;
• часто эксплуатируются в цепочке атак, например для комбинированных атак на API;
• их сложно исправить, поскольку нужно менять логику, а не кодовую строку.

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

Типичные примеры логических уязвимостей

1. IDOR — неправильная проверка доступа

IDOR (Insecure Direct Object Reference) — одна из самых распространённых логических уязвимостей. Возникает, когда приложение доверяет параметрам от клиента.

Пример:

/api/getUser?id=530

Если пользователь заменяет 530 → 531 и получает чужой профиль — это IDOR. Подобные ошибки встречаются даже в банковских приложениях.

2. Обход шагов (Step Bypass)

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

Типичные места возникновения:

• регистрация и верификация пользователя;
• оформление кредита;
• покупка товаров;
• подтверждение транзакций;
• смена пароля или почты;
• активация услуг.

3. Манипуляции с ценами и параметрами

Классическая логическая ошибка — доверие стоимости товара, переданной клиентом:

price=1.00

Если сервер не проверяет цену по базе, пользователь может купить товар за любую сумму.

4. Ошибки в обработке статусов

Частый тип логических уязвимостей — неверная работа с состояниями:

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

5. Race Conditions — гонки состояния

Если отправить два запроса одновременно, приложение может запутаться. В результате:

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

6. Недостаточные бизнес-ограничения

Зачастую логические уязвимости возникают, когда система не ограничивает действия пользователя:

• можно отправить деньги самому себе;
• можно повторно использовать купон;
• нет ограничений на количество попыток;
• можно редактировать чужие данные при определённых условиях;
• можно сменить роль пользователя без админ-права.

Как злоумышленники находят логические уязвимости?

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

Методы поиска:

1. Анализ бизнес-логики

Злоумышленник анализирует, какие действия должен выполнять пользователь и где можно нарушить процесс.

2. Попытка изменить порядок запросов

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

3. Изменение параметров запросов

• ID;
• цена;
• роль;
• статус;
• user_id;
• количество товаров.

4. Использование OSINT

OSINT помогает получить представление о логике системы, например:

• документация API;
• утекшие мануалы сотрудников;
• GitHub issues;
• публичные заявления компании;
• демо-версии приложения;
• старые версии страниц в WebArchive.

5. Анализ ошибок и поведения интерфейса

Странные сообщения, неполные проверки, доступные элементы — всё это указывает на слабые места логики.

Реальные примеры крупных взломов из-за Logic Flaws

1. Uber — баг в OAuth (2016)

Из-за логической ошибки злоумышленники получили доступ к внутреннему аккаунту, что привело к утечке данных водителей и клиентов.

2. Facebook (2018)

Ошибка логики в API позволила злоумышленникам получать токены доступа миллионов пользователей.

3. Google Pay India (2021)

Race condition позволял многократно получать cashback и выполнять транзакции без списания средств.

4. Binance (2022)

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

Методы защиты от логических уязвимостей

1. Сервер должен проверять всё

Запрещено доверять данным на стороне клиента:

• ID;
• ролям;
• цене;
• количеству товаров;
• статусам;
• наличию прав.

2. Чёткая модель состояний

Каждый шаг процесса должен быть возможен только после предыдущего.

3. Ограничение действий пользователя

Применение принципа минимальных привилегий.

4. Моделирование угроз (Threat Modeling)

Используются методологии STRIDE, PASTA, MITRE ATT&CK.

5. Ручной аудит и пентест

Только люди могут понять и оценить бизнес-логику.

6. Логирование и мониторинг

Необычные ID, двойные запросы, обход шагов должны фиксироваться и блокироваться.

Чек-лист тестирования логики (для пентестеров)

• Можно ли пропустить шаг?
• Можно ли изменить сумму?
• Можно ли изменить ID?
• Есть ли ограничения на количество действий?
• Проверяются ли права доступа на сервере?
• Корректно ли обрабатываются статусы?
• Работает ли система при параллельных запросах?
• Можно ли получить выгоду, изменив параметр?
• Можно ли получать данные других пользователей?
• Есть ли старые, забытые API-методы?

Заключение

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

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