Rate Limit Bypass

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Rate limit bypass techniques

Exploring Similar Endpoints

लक्षित endpoint के विभिन्न वेरिएंट्स पर brute force attacks करने का प्रयास किया जाना चाहिए, जैसे /api/v3/sign-up, और वैकल्पिक रूपों जैसे /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up आदि।

Incorporating Blank Characters in Code or Parameters

कोड या पैरामीटर में %00, %0d%0a, %0d, %0a, %09, %0C, %20 जैसे blank bytes सम्मिलित करना एक उपयोगी रणनीति हो सकती है। उदाहरण के लिए, पैरामीटर को code=1234%0a में बदलने से इनपुट वेरिएशनों के माध्यम से और अधिक प्रयास किए जा सकते हैं — जैसे ईमेल पते में newline characters जोड़कर प्रयास सीमाओं को बाईपास करना।

Manipulating IP Origin via Headers

Headers को बदलकर perceived IP origin को बदलना IP-based rate limiting से बचने में मदद कर सकता है। X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host जैसे headers, और X-Forwarded-For के कई instances का उपयोग करके, अलग-अलग IPs से आने वाले अनुरोधों का अनुकरण किया जा सकता है।

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

Changing Other Headers

user-agent और cookies जैसे अन्य request headers को बदलना सुझाया जाता है, क्योंकि इन्हें भी अनुरोध पैटर्न की पहचान और ट्रैकिंग के लिए उपयोग किया जा सकता है। इन हेडरों को बदलने से अनुरोधकर्ता की गतिविधियों की पहचान और ट्रैकिंग रोकी जा सकती है।

Leveraging API Gateway Behavior

कुछ API gateways इस तरह कॉन्फ़िगर किए जाते हैं कि वे endpoint और parameters के संयोजन के आधार पर rate limiting लागू करते हैं। parameter values को बदलकर या request में गैर-प्रभावी parameters जोड़कर gateway की rate-limiting लॉजिक को दरकिनार करना संभव है, जिससे हर request अनूठा दिखाई दे। उदाहरण के लिए /resetpwd?someparam=1।

Logging into Your Account Before Each Attempt

हर प्रयास से पहले, या प्रत्येक प्रयास सेट से पहले, account में लॉगिन करने से rate limit counter रीसेट हो सकता है। यह विशेष रूप से login कार्यक्षमताओं का परीक्षण करते समय उपयोगी है। Burp Suite जैसे टूल्स में Pitchfork attack का उपयोग करके हर कुछ प्रयासों पर credentials को rotate करना और सुनिश्चित करना कि follow redirects मार्क किए गए हों, rate limit counters को प्रभावी रूप से रीस्टार्ट कर सकता है।

Utilizing Proxy Networks

requests को कई IP addresses पर वितरित करने के लिए proxies के नेटवर्क को तैनात करने से IP-based rate limits को प्रभावी ढंग से बायपास किया जा सकता है। ट्रैफ़िक को विभिन्न proxies के माध्यम से रूट करके, प्रत्येक request एक अलग स्रोत से आई हुई प्रतीत होती है, जिससे rate limit की प्रभावशीलता कम हो जाती है।

Splitting the Attack Across Different Accounts or Sessions

यदि target system per-account या per-session आधार पर rate limits लागू करता है, तो हमले या टेस्ट को कई accounts या sessions में वितरित करने से पता लगाने से बचा जा सकता है। इस विधि में कई identities या session tokens का प्रबंधन आवश्यक होता है, लेकिन यह लोड को प्रभावी तरीके से वितरित करके अनुमति योग्य सीमाओं के भीतर बने रहने में मदद कर सकता है।

Keep Trying

ध्यान दें कि भले ही rate limit लागू हो, आपको यह देखने की कोशिश करनी चाहिए कि जब वैध OTP भेजा जाए तो response अलग होता है या नहीं। 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 implementations अक्सर TCP connections (or even individual HTTP/1.1 requests) को गिनते हैं बजाय number of HTTP/2 streams जो एक connection में होते हैं। जब वही TLS connection पुन: उपयोग किया जाता है, तो एक attacker सैकड़ों parallel streams खोल सकता है, प्रत्येक अलग request ले जा रहा होता है, जबकि gateway केवल one request को quota से घटाता है।

# 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

यदि limiter केवल /verify की ही सुरक्षा करता है लेकिन /api/v2/verify की नहीं, तो आप path confusion को HTTP/2 multiplexing के साथ मिलाकर बेहद हाई-स्पीड OTP या credential brute-forcing कर सकते हैं।

🐾 Tip: PortSwigger’s Turbo Intruder HTTP/2 को सपोर्ट करता है और maxConcurrentConnections और requestsPerConnection को fine-tune करने देता है ताकि आप इस attack को automate कर सकें।

GraphQL aliases & batched operations

GraphQL क्लाइंट को एक single request में aliases का उपयोग करके कई तार्किक रूप से स्वतंत्र queries या mutations भेजने की अनुमति देता है। चूंकि सर्वर हर alias को execute करता है लेकिन rate-limiter अक्सर केवल एक request के रूप में गिनता है, यह login या password-reset throttling के लिए एक भरोसेमंद bypass है।

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 होंगे।

The technique was popularised by PortSwigger’s research on “GraphQL batching & aliases” in 2023 and has been responsible for many recent bug-bounty payouts।

Abuse of batch or bulk REST endpoints

कुछ APIs ऐसे helper endpoints expose करते हैं जैसे /v2/batch या request body में array of objects स्वीकार करते हैं। अगर limiter केवल legacy endpoints के सामने रखा गया है, तो एक ही bulk request के अंदर कई operations को रैप करने से protection को पूरी तरह sidestep किया जा सकता है।

[
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
]

sliding-window का समय निर्धारण

एक classic token-bucket या leaky-bucket limiter निश्चित समय सीमा पर resets होता है (उदाहरण के लिए, हर मिनट)। यदि विंडो ज्ञात है (उदा. X-RateLimit-Reset: 27 जैसे error messages से), तो बकेट रिसेट होने से ठीक पहले अधिकतम अनुमति दी गई requests भेजें, और तुरंत एक और पूरा burst भेजें।

|<-- 60 s window ‑->|<-- 60 s window ‑->|
######                 ######

यह सरल optimisation आपकी थ्रूपुट को बिना किसी अन्य bypass technique को छुए दोगुना से भी अधिक कर सकता है।

हैंडशेक के बाद WebSockets / gRPC streaming में अपग्रेड करना

कई edge rate-limiters केवल initial HTTP request की ही जांच करते हैं। एक बार कनेक्शन WebSocket (HTTP 101) या gRPC bidirectional streaming में अपग्रेड हो जाने के बाद, बाद के संदेश अक्सर request-per-second काउंटरों को bypass कर देते हैं, क्योंकि वे अब अलग-अलग HTTP requests नहीं होते। Cloudflare के अपने docs में उल्लेख है कि केवल initial upgrade request ही WAF/rate-limiting नियमों के अंतर्गत आता है; बाद में भेजे गए frames अस्पष्ट होते हैं।

व्यावहारिक 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 variants एक्सपोज़ करता है, तो पहले upgraded channel स्थापित करें और फिर उसी single connection के भीतर codes स्प्रे करें ताकि per-request throttles से बचा जा सके।

CDN PoP‑sharded counters का शोषण

कुछ CDN rate-limit counters per data center/PoP instead of globally shard करते हैं। Cloudflare स्पष्ट रूप से बताता है कि counters data centers के बीच share नहीं होते। कई regions में मौजूद egress nodes (residential proxy pools, anycast VPNs, or cloud VMs pinned to different continents) के माध्यम से requests route करके आप allowed throughput को गुणा कर सकते हैं: हर PoP उसी key के लिए एक स्वतंत्र bucket रखता है।

Quick and dirty layout using open proxies (example with 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 per-account न हो; अन्यथा user IDs / session tokens भी rotate करें।

उपकरण

  • 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 बनाता है ताकि हर request अलग IP address से उत्पन्न हो – IP-based throttling को हराने के लिए उपयुक्त।
  • Burp Suite – IPRotate + extension: SOCKS/HTTP proxies (या AWS API Gateway) के एक पूल का उपयोग करता है ताकि source IP पारदर्शी रूप से rotate हो सके Intruder और Turbo Intruder हमलों के दौरान।
  • Turbo Intruder (BApp): High-performance attack engine जो HTTP/2 multiplexing को सपोर्ट करता है; requestsPerConnection को 100-1000 पर सेट करें ताकि सैकड़ों requests एक single connection में समा जाएँ।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें