Распространенные векторы атак race condition в веб-приложениях 🤔

Race condition редко находятся автоматическими сканерами. Это уязвимости не про пэйлоад, а про тайминг, состояние и бизнес-логику.

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

Ниже — два рабочих вектора, которые чаще всего выстреливают 💸

HTTP/1.1 last-byte синхронизация

Атака эксплуатирует то, как сервер обрабатывает частично отправленные запросы.

Сценарий:

✅ Открыть первый запрос и удерживать соединение (не отправлять весь контент сразу).

✅ Отправить второй запрос в момент, когда первый ещё обрабатывается.

✅ Добиться перекрытия операций проверки и изменения состояния.

Так ломаются проверки лимитов, купоны, списания и другие бизнес-процессы.

HTTP/2 single-packet атаки

HTTP/2 ускоряет запросы, но даёт атакующему контроль над таймингом.

Сценарий:

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

✅ После паузы завершить все запросы одновременно одним TCP-пакетом.

✅ Минимизировать сетевой джиттер и повысить стабильность гонки.

Метод особенно эффективен против логики, не рассчитанной на параллельность.

Что можно сломать

Последствия race condition чаще всего логические:

➖ двойное списание средств;
➖ повторное применение купонов и бонусов;
➖ обход ограничений и лимитов;
➖ неконсистентное состояние данных,
➖ DoS и ошибки контроля доступа,

По импакту такие баги часто уходят в high или critical.

P. S. Для эксплуатации используй Burp Suite Turbo Intruder, а практику оттачивай на Web Security Academy 😓