Rate Limit Bypass
Tip
Вивчайте та практикуйте AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.
Rate limit bypass techniques
Дослідження схожих endpoint’ів
Слід намагатися виконувати brute force атаки на варіації цільового endpoint, такі як /api/v3/sign-up, включаючи альтернативи на кшталт /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up тощо.
Вставлення порожніх символів у код або параметри
Вставлення порожніх байтів, таких як %00, %0d%0a, %0d, %0a, %09, %0C, %20, у код або параметри може бути корисною стратегією. Наприклад, змінивши параметр на code=1234%0a, можна розширити кількість спроб через варіації вводу — наприклад, додаванням символів нового рядка до email-адреси, щоб обійти обмеження на кількість спроб.
Маніпулювання походженням IP через headers
Зміна headers, щоб підмінити сприймане походження IP, може допомогти уникнути IP-based rate limiting. Заголовки, такі як X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, включаючи використання кількох екземплярів X-Forwarded-For, можна змінювати, щоб імітувати запити з різних IP.
X-Originating-IP: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Host: 127.0.0.1
X-Forwared-Host: 127.0.0.1
# Double X-Forwarded-For header example
X-Forwarded-For:
X-Forwarded-For: 127.0.0.1
Зміна інших заголовків
Змінювати інші заголовки запиту, такі як user-agent та cookies, рекомендується, оскільки їх також можна використовувати для ідентифікації та відстеження шаблонів запитів. Зміна цих заголовків може перешкодити розпізнаванню та відстеженню дій запитувача.
Використання поведінки API Gateway
Деякі API gateway налаштовані застосовувати rate limiting на основі комбінації endpoint і параметрів. Варіюючи значення параметрів або додаючи несуттєві параметри до запиту, можна обійти логіку rate-limiting шлюзу та зробити кожен запит унікальним. Наприклад /resetpwd?someparam=1.
Вхід у ваш акаунт перед кожною спробою
Вхід в акаунт перед кожною спробою або кожною серією спроб може скинути лічильник rate limit. Це особливо корисно при тестуванні функціоналу логіну. Використання Pitchfork attack у таких інструментах, як Burp Suite, для ротації облікових даних кожні кілька спроб і переконання, що follow redirects увімкнено, може ефективно перезапустити лічильники rate limit.
Використання мереж проксі
Розгортання мережі proxies для розподілу запитів між кількома IP-адресами може ефективно обійти IP-based rate limits. Маршрутизуючи трафік через різні proxies, кожен запит здається таким, що походить з іншого джерела, знижуючи ефективність rate limit.
Розподіл атаки між різними акаунтами або сесіями
Якщо цільова система застосовує rate limits для кожного акаунта або сесії, розподіл атаки або тесту між кількома акаунтами чи сесіями може допомогти уникнути виявлення. Цей підхід вимагає керування кількома ідентичностями або session tokens, але може ефективно розподілити навантаження, щоб залишатися в межах дозволених лімітів.
Keep Trying
Note that even if a rate limit is in place you should try to see if the response is different when the valid OTP is sent. In this post, the bug hunter discovered that even if a rate limit is triggered after 20 unsuccessful attempts by responding with 401, if the valid one was sent a 200 response was received.
Abusing HTTP/2 multiplexing & request pipelining (2023-2025)
Сучасні реалізації rate–limiter часто рахує TCP connections (або навіть окремі HTTP/1.1 requests) замість number of HTTP/2 streams, які містить одне з’єднання. Якщо той самий TLS connection повторно використовується, attacker може відкрити сотні паралельних streams, кожен з яких містить окремий request, тоді як gateway списує лише one request з квоти.
# Send 100 POST requests in a single HTTP/2 connection with curl
seq 1 100 | xargs -I@ -P0 curl -k --http2-prior-knowledge -X POST \
-H "Content-Type: application/json" \
-d '{"code":"@"}' https://target/api/v2/verify &>/dev/null
Якщо лімітер захищає лише /verify, але не /api/v2/verify, ви також можете поєднати path confusion з HTTP/2 multiplexing для надзвичайно високошвидкісного перебору OTP або credential brute-forcing.
🐾 Порада: PortSwigger’s Turbo Intruder підтримує HTTP/2 і дозволяє тонко налаштувати
maxConcurrentConnectionsтаrequestsPerConnection, щоб автоматизувати цю атаку.
GraphQL aliases & batched operations
GraphQL дозволяє клієнту відправляти кілька логічно незалежних queries або mutations в одному запиті, префіксувавши їх aliases. Оскільки сервер виконує кожен alias, але rate-limiter часто рахує лише один запит, це є надійним bypass для login або password-reset throttling.
mutation bruteForceOTP {
a: verify(code:"111111") { token }
b: verify(code:"222222") { token }
c: verify(code:"333333") { token }
# … add up to dozens of aliases …
}
Подивіться на відповідь: рівно один alias поверне 200 OK, коли буде вгадано правильний код, у той час як інші будуть rate-limited.
Техніка набула поширення завдяки дослідженню PortSwigger’s “GraphQL batching & aliases” у 2023 році і призвела до багатьох нещодавніх bug-bounty виплат.
Зловживання batch або bulk REST endpoints
Деякі APIs expose helper endpoints, такі як /v2/batch, або приймають array of objects у request body. Якщо limiter розташований лише перед legacy endpoints, упаковка кількох операцій у один bulk request може повністю обійти захист.
[
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
]
Таймінг sliding-window
Класичний token-bucket або leaky-bucket обмежувач скидається на фіксованій часовій межі (наприклад, щохвилини). Якщо вікно відоме (наприклад, через повідомлення про помилку, такі як X-RateLimit-Reset: 27), відправте максимально дозволену кількість запитів безпосередньо перед тим, як bucket скинеться, а потім одразу відправте ще один повний сплеск.
|<-- 60 s window ‑->|<-- 60 s window ‑->|
###### ######
Ця проста оптимізація може більш ніж удвічі збільшити ваш throughput без зміни інших bypass techniques.
Оновлення до WebSockets / gRPC streaming після handshake
Багато edge rate-limiters перевіряють лише початковий HTTP-запит. Після того як з’єднання оновлено до WebSocket (HTTP 101) або gRPC bidirectional streaming, подальші повідомлення часто обходять request-per-second лічильники, оскільки більше не є окремими HTTP-запитами. У документації Cloudflare зазначено, що лише початковий upgrade request підпадає під WAF/rate-limiting rules; фрейми, відправлені пізніше, є неінтерпретованими.
Практичний workflow:
# Flood 1,000 OTP guesses through a single WebSocket connection
seq -w 000000 000999 | websocat -n ws://target.tld/api/verify-ws
# gRPC streaming: send multiple Verify requests in one stream
grpcurl -d @ -plaintext target.tld:50051 service.VerifyOTP/Stream <<'EOF'
{ "code": "111111" }
{ "code": "222222" }
{ "code": "333333" }
EOF
Якщо login/OTP endpoint надає і HTTP, і WebSocket/gRPC варіанти, спочатку встановіть upgraded channel, а потім spray codes у межах одного з’єднання, щоб обійти per-request throttles.
Використання CDN PoP‑sharded counters
Деякі CDN шардять rate-limit counters по дата-центру/PoP замість глобально. Cloudflare явно вказує, що counters не діляться між дата-центрами. Маршрутизуючи запити через egress nodes у багатьох регіонах (residential proxy pools, anycast VPNs або cloud VMs, прив’язані до різних континентів), ви множите дозволену пропускну здатність: кожен PoP підтримує незалежний bucket для того самого ключа.
Швидка й груба схема з використанням open proxies (приклад з proxychains + a country‑rotating list):
for p in $(cat proxies.txt); do
HTTPS_PROXY=$p curl -s -X POST https://target/api/login -d @payload.json &
done
wait
Переконайтеся, що limiter key не є прив’язаним до облікового запису; інакше також періодично змінюйте user IDs / session tokens.
Інструменти
- https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing tool, що підтримує header randomisation, chunked word-lists та round-robin proxy rotation.
- https://github.com/ustayready/fireprox: Автоматично створює disposable AWS API Gateway endpoints, тож кожен запит походить з різної IP-адреси — ідеально для обходу IP-based throttling.
- Burp Suite – IPRotate + extension: Використовує пул SOCKS/HTTP proxies (або AWS API Gateway) для прозорої ротації джерела IP під час Intruder та Turbo Intruder атак.
- Turbo Intruder (BApp): Високопродуктивний attack engine, що підтримує HTTP/2 multiplexing; налаштуйте
requestsPerConnectionна 100–1000, щоб згорнути сотні запитів в одне з’єднання.
Джерела
- PortSwigger Research – “Bypassing rate limits with GraphQL aliasing” (2023)
- PortSwigger Research – “HTTP/2: The Sequel is Always Worse” (connection-based throttling) (2024)
- Cloudflare Docs – WebSockets & WAF applicability (2025)
- Cloudflare Docs – Request rate calculation and PoP-local counters (2025)
Tip
Вивчайте та практикуйте AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Вивчайте та практикуйте Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Підтримайте HackTricks
- Перевірте плани підписки!
- Приєднуйтесь до 💬 групи Discord або групи telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
- Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на github.


