Rate Limiting Bypass — повний розбір, техніки обходу, реальні кейси та методи захисту

Rate limiting — це один з ключових механізмів захисту вебдодатків і API, який обмежує кількість запитів за певний проміжок часу. Його мета — блокувати brute force, credential stuffing, enumeration, DDoS-подібні атаки та інші шкідливі дії.
Але, як показує практика, майже всі популярні вебсервіси, від стартапів до корпорацій рівня Google, PayPal, Uber, TikTok, неодноразово страждали від успішного обходу rate limiting.
У цій статті ми докладно розглянемо, як працює rate limiting, якими техніками зловмисники обходять обмеження, та наведемо реальні приклади з bug bounty і Red Team-практики. Вся стаття сфокусована на практичних аспектах.

1. Що таке Rate Limiting і чому його атакують?

Rate limiting — це контроль швидкості обробки запитів. Типові формули:

• 10 запитів на IP / за 1 хвилину
• 3 спроби логіну / за 15 хвилин
• 100 API-викликів на access-token / годину

Атакують rate limits, тому що їх обхід дозволяє:

• масово підбирати паролі (credential stuffing)
• брютфорсити OTP / MFA коди
• масово створювати акаунти (signup automation)
• робити парсинг/скрейпінг без блокування
• здійснювати атакуючі дії непомітно

Сам обхід не є уразливістю, але він робить можливими критичні атаки іншого типу. Тому в bug bounty такі баги часто високого рівня.

2. Як працює Rate Limiting: базові механізми

Перш ніж зрозуміти, як обійти rate limiting, потрібно знати, як він зазвичай працює. Системи обмежень використовують кілька базових моделей:

2.1 Rate limiting по IP

Найпоширеніший: усі запити з одного IP адреси записуються у лічильник.

Проблема: IP можна легко підробити або замінити проксі.

2.2 Rate limiting по session / cookie

Використовується в вебдодатках, де у кожного юзера є cookie.

Проблема: cookie можна змінити / видалити / підробити.

2.3 Rate limiting по API-ключу

Працює для публічних API.

Проблема: API-ключ можна автоматично міняти або створювати нові облікові записи.

2.4 Rate limiting по user-id / account-id

Застосовується після аутентифікації.

Проблема: можливість атакувати інші endpoints до логіну або на рівні reverse proxy.

3. Основні техніки обходу Rate Limiting

3.1 Ротація IP-адрес (Residential, Mobile, Proxy Pools)

Найпростіший спосіб — міняти IP після кожного запиту. Атакуючий може використовувати:

• TOR (повільно, але працює)
• Mobile proxy (4G/5G з мільйонами IP)
• Residential proxy (дуже ефективно)
• Self-hosted VPS pool

Такі атаки отримали назву «IP Spraying».
Багато API не мають кореляції між IP та акаунтом, тому rate limiting просто не спрацьовує.

3.2 Обхід через X-Forwarded-For, X-Real-IP, True-Client-IP

Один з найвідоміших методів:

Сервер використовує заголовок X-Forwarded-For для визначення «мережевої» IP адреси користувача.
Атакуючий надсилає кожен запит з іншим значенням:

X-Forwarded-For: 1.1.1.1
X-Forwarded-For: 1.1.1.2
X-Forwarded-For: 1.1.1.3
...

Якщо backend довіряє цьому заголовку — rate limiting зламаний.

Це був класичний баг в Uber API (винагорода: $3,000).

3.3 Обхід через HTTP заголовки клієнта

Деякі системи використовують заголовки для ідентифікації пристрою:

• User-Agent
• Device-ID
• Client-Version
• Accept-Language

Якщо rate limiting прив’язаний до Device-ID, атакуючий може рендомізувати його:

Device-ID: ATTACKER-DEVICE-001
Device-ID: ATTACKER-DEVICE-002
...

3.4 Обхід через POST → GET або навпаки

Багато backend систем мають обмеження тільки на POST-запити, але не на GET.
Дослідники Google Project Zero знаходили такі помилки навіть у великих сервісах.

3.5 Обхід через різні endpoints → одна дія

Наприклад:

• /api/login
• /api/session/create
• /auth/login

Якщо один endpoint має rate-limiting, а інший — ні, можна атакувати відкритий.

Таку помилку знаходили у Airbnb (bug bounty).

3.6 Обхід через GraphQL

GraphQL часто не має rate limiting всередині одного запиту.
Атакуючий може робити запити з 50 підзапитами — система бачить його як 1 запит.

3.7 Обхід через HTTP/2 Parallel Streams

Це сучасна техніка:

HTTP/2 дозволяє відправляти десятки запитів у рамках одного TCP-з’єднання. Якщо rate limiting прив’язаний до TCP-socket — обхід гарантований.

3.8 Multiplexing / Batch API

Деякі API дозволяють відправляти кілька команд у одному запиті:

{
  "requests": [
    {"phone": "111111"},
    {"phone": "222222"},
    {"phone": "333333"}
  ]
}

Таким чином можна зробити 100 підзапитів у межах одного API call.

3.9 Обхід через нестандартні HTTP методи

Rate limiting може діяти тільки на POST/GET, але не на:

• HEAD
• OPTIONS
• PUT
• PATCH

У 2022 році знайшли баг у великому фінтех-сервісі:
PUT /login не мав обмеження.

3.10 Обхід через DNS / субдомени

Якщо сервер має різні rate limits на різних субдоменах:

• api.example.com
• m.example.com
• beta.example.com

То атакуючий може відправляти запити паралельно.

4. Реальні приклади з Bug Bounty

4.1 TikTok — обхід rate limit при відправці OTP

Нагорода: $18,000
Дослідник обійшов rate limit SMS-OTP за допомогою X-Forwarded-For.
TikTok довіряв цьому заголовку — backend думав, що кожен запит з нового IP.

4.2 Uber — логін без обмеження brute force

Нагорода: $3,500
API довіряло заголовку X-Real-IP.
Атакуючий міг рендомізувати значення та підбирати паролі.

4.3 Instagram — bypass rate limit у recovery endpoint

Нагорода: $6,500
Не було обмеження по device-id, тільки по IP.
Mobile proxy дозволив атакувати endpoint з тисяч IP за хвилину.

4.4 Google — обхід rate limiting у /accounts/recovery

Нагорода: $7,000
Ключовий баг: rate limiting застосовувався тільки до POST,
але GET endpoint робив ту саму дію та не був захищений.

4.5 PayPal — відсутність rate limiting у email-lookup

Нагорода: $10,500
Атакуючий міг масово перевіряти email адреси на існування.

5. Advanced техніки обходу (Red Team рівень)

5.1 Distributed Low & Slow Attack

Ідея: не спамити, а робити “повільний розподілений” brute force:

• 1 запит в хвилину з кожного IP
• 10000 IP = 10000 спроб в хвилину

5.2 DNS Rebinding для заміни джерела запитів

Атакуючий створює домен, який змінює IP через секунду після резолву.
Це дозволяє обходити IP-базований rate limiting.

5.3 Багатопоточні WebSocket-атаки

WebSocket часто не має rate limiting зовсім.
Через один сокет можна робити сотні запитів в секунду.

5.4 Маскування запитів під системні

Деякі CDN (Akamai, Cloudflare) пропускають системні User-Agent.
Атакуючий видає себе за Googlebot / UA Crawler.

6. Обхід rate limiting у MFA/OTP системах

Один з найнебезпечніших сценаріїв — обхід rate limiting у SMS або TOTP.
Помилка часто дозволяє brute-force 6-значного коду, що призводить до реального злому акаунтів.

Типові баги:

• Rate-limiting прив’язаний тільки до session-id
• Відсутність обмежень на alternative OTP endpoint
• Баг у resend-endpoint (можна відправити 1000 SMS)

Meta виплатила $20,000 за такий баг у 2022 році.

7. Obfuscation техніки

Креативні методи:

• Запити з різною кодуванням URL (Unicode bypass)
• Double URL encoding
• IPv6 → IPv4 трансляція
• Header smuggling
• Chunked transfer encoding

Ці методи інколи ламають алгоритм rate-ліміту, через неправильні парсери.

8. Як захищатися? (Best Practices 2024)

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

8.1 Коректна ідентифікація клієнта

Rate limiting має бути прив’язаний до:

• IP + session + user-id + fingerprint
• поведінкових параметрів (behavioral analytics)
• геолокації
• мережевого провайдера

8.2 Недовіра до X-Forwarded-For

Потрібно використовувати:

real_ip_header CF-Connecting-IP;

або whitelist для проксі.

8.3 Обмеження на всі endpoints

• POST
• GET
• PUT/PATCH
• GraphQL
• WebSocket

8.4 Захист від автоматизації

• ReCAPTCHA v3 / ArkoseLabs
• Device fingerprinting
• Bot detection системи

8.5 Correlation-based limiting

Приклад:
10 різних IP, які роблять однакові запити — підозрілі.

9. Висновок

Обхід rate limiting — одна з найпоширеніших та найкритичніших технік атак на сучасні API.
Система обмеження запитів здається простою, але на практиці вона містить величезну кількість помилок через неправильну конфігурацію, недовіру до заголовків, недосконалу логіку або відсутність кореляції даних.

Зловмисники використовують десятки методів, від простих X-Forwarded-For до складних розподілених атак через HTTP/2 streams, WebSocket і DNS-rebinding.
Тому без комплексної архітектури захисту обходу не уникнути.

Дана стаття охоплює основні та просунуті техніки обходу, реальні кейси та практичні методи протидії — і є повноцінним довідником для OSINT, Bug Bounty, Red Team та Blue Team спеціалістів.