Одна глава из книги про бизнес-логику: «Исповедь баг-хантера: Взлом без лишней воды». Сейчас можно оформить предзаказ, по цене: 1499 руб. Цена, после релиза: 2200 руб.

Раздел 10.1. Почему дорогие баги часто выглядят скучно

Представь, что ты нашел крутую SQL-инъекцию, обфусцировал пейлоад, обошел WAF и вытащил таблицу users. Это красиво, технично и требует глубоких знаний. Ты сдаешь репорт, получаешь $5,000 и статус хакера.

А теперь представь другую ситуацию. В магазине есть купон DISCOUNT10 на скидку 10%. Ты кидаешь этот купон в корзину в Burp Repeater. А потом нажимаешь кнопку Send 20 раз подряд (Race Condition) или отправляешь массив ["DISCOUNT10", "DISCOUNT10"] (как мы обсуждали в Главе 3). Сумма заказа становится отрицательной. Магазин должен тебе денег.
В этом запросе нет ни одной строчки хакерского кода. Нет обходов WAF. Запрос выглядит так, будто его отправил легитимный пользователь. Это скучно? Для скрипт-кидди - да. Но триажер выплатит тебе за это $10,000+, потому что ты нашел баг, который напрямую ведет к финансовым потерям компании.

Иллюзия защищенности: Почему логика дырявая?

Баги бизнес-логики (Application Logic Flaws) возникают на стыке двух миров: того, как приложение задумывалось, и того, как оно написано.

Разработчики мыслят "счастливыми путями" (Happy Paths).

• Шаг 1: Юзер выбирает товар.
• Шаг 2: Юзер оплачивает товар.
• Шаг 3: Юзер получает товар.

Как мыслит ремесленник? Он ломает конечный автомат (State Machine).

• А что если я перейду к Шагу 3, пропустив Шаг 2? (Missing Transition Validation ).
• А что если я нажму "Отмена заказа" в момент, когда платежный шлюз уже ответил "Ок", но сервер еще не отгрузил товар?
• А что если я добавлю в корзину 1 телевизор, а потом изменю количество на -1? Будет ли итоговая сумма к оплате минусовой?

OWASP Top 10 для Бизнес-Логики

Если классический OWASP Top 10 учит нас защищаться от SQLi и XSS, то для логики есть свои паттерны. Давай разберем самые прибыльные:

1. Action Limit Overrun (Обход лимитов)
   Система говорит: "Один купон в одни руки" или "3 бесплатные статьи в месяц".
   Как ломаем: Race Condition (отправка 50 запросов за 1 миллисекунду). База данных не успевает обновить счетчик использований, и все 50 потоков проходят проверку if (usage_count < 1). Итог: безлимитные скидки или накрутка реферальной программы.

2. Workflow Order Bypass (Нарушение порядка шагов)
   В банковском приложении: Ввод карты -> СМС код -> Списание денег.
   Как ломаем: Мы перехватываем POST-запрос с шага "Списание денег" и сохраняем его. Начинаем новую транзакцию, вводим карту, и вместо ожидания СМС сразу отправляем сохраненный финальный POST-запрос. Если сервер не проверяет, прошли ли мы предыдущие шаги в этой конкретной сессии, он спишет деньги без СМС!.

3. Object State Manipulations (Манипуляция состояниями)
   Это наш любимый Mass Assignment. Заказ имеет статусы: new, paid, shipped, cancelled.
   Как ломаем: При обновлении адреса доставки мы докидываем в JSON поле {"status": "paid"}. Сервер слепо обновляет базу, и мы получаем бесплатный товар.

Сканеры тут бессильны (The Automation Blind Spot)

Почему автоматика никогда не найдет такие баги?
Потому что сканер не понимает контекста. Сканер видит эндпоинт POST /api/cart/add. Он может подставить туда id=1' OR 1=1. Но он никогда не додумается подставить id=1&qty=-500, потому что он не знает, что такое "количество товара" и как оно влияет на "общую сумму".

Чтобы находить бизнес-логику, ты должен стать тестировщиком (QA Engineer), но с криминальным уклоном.

Практика: От приглашения друга до взлома биллинга (Кейс)

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

🔍 Точка входа: B2B платформа. Подписка стоит $50 за пользователя в месяц. Есть фича "Пригласи команду". За каждого нового приглашенного члена команды с баланса владельца списывается $50.
💻 Что бросилось в глаза: Хантер заходит под аккаунтом Владельца. Нажимает "Пригласить", вводит email test@mail.com. Сервер отправляет инвайт, но деньги не списывает, потому что юзер еще не принял приглашение. (Баланс: $0).
💣 Векторы атак: Race Condition (состояние гонки) и Action Limit Overrun.
💀 Команды и эксплойты:

1. Хантер замечает, что можно пригласить еще одного человека на тот же самый email, если он еще не принял первое приглашение.
2. Хантер отправляет еще 5 инвайтов на test@mail.com. Баланс всё еще $0 (так как инвайты не приняты).
3. Теперь самое интересное. Хантер открывает почту test@mail.com и видит 6 ссылок-приглашений.
4. Он кликает по первой ссылке. Юзер добавляется в команду, с баланса Владельца списывается $50.
5. Он кликает по остальным 5 ссылкам.
   🛠 Лайфхаки: БИНГО! Что произошло? Платформа добавила одного и того же человека в команду 6 раз, потому что ссылки были сгенерированы до того, как человек присоединился. Но из-за ошибки в логике биллинга (система думала, что это один юзер, который просто много раз нажал на ссылку), деньги за следующие 5 активаций не списались!
   Хантер смог добавить 100 юзеров (через скрипт) по цене одного. Прямой финансовый убыток компании.
   Никаких кавычек. Никаких XSS. Только понимание того, как работает биллинг, и использование легитимных ссылок не по правилам. И помни: 0day - как любовь: нашел баг в деньгах - не воруй миллионы, докажи на $100 и пиши Critical.

Бизнес-логика - это шахматы. Ты должен прочитать правила игры (документацию), понять, как ходят фигуры (перехватить трафик в Burp), а затем найти ход, который правила не запрещают, но создатель игры не предусмотрел.