Rate Limiting только на бумаге: как лимиты в веб-приложении не остановили abuse

Контекст

• Объект: веб-приложение с email/password login, recovery flow и одноразовыми кодами.
• Метод: black-box тестирование поведения auth flow и recovery flow без исходников.
• NDA: название компании, точные URL и доменные детали скрыты.
• Вердикт: до исправления лимитов и корреляции попыток auth/recovery поток нельзя считать защищённым от массового abuse.

Что именно пошло не так

V01 — Login rate limit срабатывал только “по красивому сценарию” (HIGH)

Ограничение на вход было привязано только к одной комбинации признаков и не учитывало нормальную картину реальной атаки: смену IP, заголовков и распределённые попытки против одного аккаунта. В итоге лимит можно было обойти, не ломая протокол и не трогая экзотические payload’ы.

PoC (обезличенно)

Упрощённая логика наблюдения:

POST /auth/login
POST /auth/login
POST /auth/login
...

Ожидание: 429 Too Many Requests + устойчивый lockout
Факт: часть попыток продолжала получать обычные ответы приложения

V02 — Resend OTP можно было вызывать слишком часто (HIGH)

Поток повторной отправки одноразового кода имел локальные задержки, но не имел внятного глобального ограничения на сущность пользователя/сессию/канал доставки. Для атакующего это превращается в удобный механизм SMS/email flooding против конкретной жертвы.

V03 — Password reset flow не был связан с общим anti-abuse контуром (MEDIUM/HIGH)

Recovery flow жил отдельно от login flow: лимиты считались отдельно, события не коррелировались, а значит атакующий мог комбинировать разные точки входа в одну сессию злоупотребления. В реальной атаке именно такие “стыки” и дают масштабирование.

Почему это опасно для бизнеса

• Account Takeover: если у атакующего есть база логинов и слабых паролей, отсутствие нормального rate limiting резко повышает шанс захвата аккаунтов.
• Support cost: SMS/email bombing и reset-abuse быстро превращаются в поток жалоб и ручных разборов саппорта.
• Infrastructure noise: recovery и OTP тянут за собой внешние сервисы, провайдеров сообщений и лишние расходы.
• False confidence: команда видит “лимиты включены”, но на деле они не останавливают реального атакующего.

Что было сделано правильно

• Часть эндпоинтов уже отвечала 429, то есть идея защиты присутствовала.
• Были локальные cooldown-механизмы для отдельных действий.
• Auth flow не раскрывал лишних деталей о существовании аккаунта в некоторых сценариях.

Рекомендации по исправлению

1. Считать лимиты по нескольким осям сразу: account, IP / IP range, device fingerprint, recovery target.
2. Связать login, reset и resend OTP в единый anti-abuse контур, а не держать отдельные лимиты на каждый эндпоинт.
3. Добавить progressive backoff и более жёсткий lockout для повторяющихся атак на один и тот же аккаунт.
4. Логировать события в одном месте: чтобы security и support видели коррелированную картину, а не три разрозненных потока.
5. Добавить regression checks на rate limiting в CI / pre-prod, чтобы защита не “исчезала” при следующем рефакторинге auth flow.

Практический вывод

Rate limiting — это не чекбокс “включено / выключено”. Это поведение системы под реальной нагрузкой и реальным злоупотреблением. Если защита не считает сущности, не склеивает события между потоками и не выдерживает нормальную вариативность клиента, то для бизнеса она почти бесполезна.