Rate Limit Bypass

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Rate limit bypass tegnieke

Verkenning van soortgelyke endpoints

Daar moet probeer word om brute force-aanvalle op variasies van die geteikende endpoint uit te voer, soos /api/v3/sign-up, insluitend alternatiewe soos /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up ens.

Inkorporering van leë karakters in code of parameters

Die invoeging van leë bytes soos %00, %0d%0a, %0d, %0a, %09, %0C, %20 in code of parameters kan ’n nuttige strategie wees. Byvoorbeeld, deur ’n parameter aan te pas na code=1234%0a kan pogings uitgebrei word deur variasies in invoer — soos om newline characters by ’n e-posadres te voeg om pogingbeperkings te omseil.

Manipulasie van IP-oorsprong via headers

Die wysiging van headers om die waargenome IP-oorsprong te verander kan help om IP-gebaseerde rate limiting te ontduik. Headers soos X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, insluitend die gebruik van meerdere instansies van X-Forwarded-For, kan aangepas word om versoeke van verskillende IP’s te simuleer.

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

Dit word aanbeveel om ander versoek headers soos user-agent en cookies te verander, aangesien dit ook gebruik kan word om versoekpatrone te identifiseer en te volg. Deur hierdie headers te verander kan herkenning en nasporing van die versoeker se aktiwiteite voorkom word.

Leveraging API Gateway Behavior

Sommige API gateways is gekonfigureer om rate limiting toe te pas gebaseer op die kombinasie van endpoint en parameters. Deur parameterwaardes te varieer of nie-betekenisvolle parameters by die versoek te voeg, is dit moontlik om die gateway se rate-limiting logika te omseil, sodat elke versoek uniek voorkom. Byvoorbeeld /resetpwd?someparam=1.

Logging into Your Account Before Each Attempt

Om voor elke poging, of elke reeks pogings, by ’n rekening aan te meld kan die rate limit-teller terugstel. Dit is veral nuttig wanneer login-funksionaliteit getoets word. Deur ’n Pitchfork attack in gereedskap soos Burp Suite te gebruik om kredensiële inligting elke paar pogings te roteer, en te verseker dat follow redirects gemerk is, kan rate limit-tellers effektief herbegin.

Utilizing Proxy Networks

Deur ’n netwerk van proxies te gebruik om versoeke oor meerdere IP-adresse te versprei, kan IP-gebaseerde rate limits effektief omseil word. Deur verkeer deur verskeie proxies te stuur, lyk dit asof elke versoek van ’n ander bron kom, wat die doeltreffendheid van die rate limit verdun.

Splitting the Attack Across Different Accounts or Sessions

As die teikenstelsel rate limits per rekening of per sessie toepas, kan die aanval of toets oor verskeie rekeninge of sessies versprei help om opsporing te vermy. Hierdie benadering vereis die bestuur van meerdere identiteite of sessietokens, maar kan die las effektief versprei sodat dit binne toelaatbare perke bly.

Keep Trying

Let wel dat selfs as ’n rate limit bestaan, jy moet probeer om te sien of die reaksie anders is wanneer die geldige OTP gestuur word. In this post, het die bug hunter ontdek dat selfs al word ’n rate limit geaktiveer na 20 onsuksesvolle pogings deur met 401 te reageer, as die geldige een gestuur is, ’n 200 reaksie ontvang is.

Abusing HTTP/2 multiplexing & request pipelining (2023-2025)

Moderne rate–limiter-implementasies tel gereeld TCP connections (of selfs individuele HTTP/1.1 requests) in plaas van die number of HTTP/2 streams wat ’n verbinding bevat. Wanneer dieselfde TLS connection hergebruik word, kan ’n aanvaller honderde parallelle streams oopmaak, elkeen wat ’n aparte versoek dra, terwyl die gateway net een versoek van die kwota aftrek.

# 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

As die limiter slegs /verify beskerm maar nie /api/v2/verify nie, kan jy ook path confusion met HTTP/2 multiplexing kombineer vir uiters hoëspoed OTP- of credential brute-forcing.

🐾 Tip: PortSwigger’s Turbo Intruder ondersteun HTTP/2 en laat jou toe om maxConcurrentConnections en requestsPerConnection fyn af te stel om hierdie aanval te outomatiseer.

GraphQL aliases & batched operations

GraphQL laat die kliënt toe om verskeie logies onafhanklike queries of mutations in ’n enkele request te stuur deur hulle met aliases voor te voeg. Omdat die bediener elke alias uitvoer, maar die rate-limiter dikwels slegs een request tel, is dit ’n betroubare omseiling vir login- of 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 …
}

Kyk na die response: presies een alias sal 200 OK teruggee wanneer die korrekte kode getref word, terwyl die ander rate-limited is.

Die tegniek is gepopulariseer deur PortSwigger’s research on “GraphQL batching & aliases” in 2023 en het gelei tot baie onlangse bug-bounty payouts.

Misbruik van batch of bulk REST endpoints

Sommige APIs stel helper endpoints beskikbaar soos /v2/batch of aanvaar ’n array of objects in die request body. As die limiter slegs vóór die legacy endpoints geplaas is, kan die verpakking van verskeie operasies binne ’n enkele bulk request die beskerming heeltemal omseil.

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

Tydsberekening van die sliding-window

’n klassieke token-bucket of leaky-bucket limiter resets op ’n vaste tydgrens (byvoorbeeld elke minuut). As die venster bekend is (bv. via foutboodskappe soos X-RateLimit-Reset: 27), stuur die maksimum toegelate aantal versoeke net voordat die bucket resets, en stuur dan onmiddellik nog ’n volle burst.

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

Hierdie eenvoudige optimalisering kan jou deurset meer as verdubbel sonder om enige ander bypass technique aan te raak.

Opgradeer na WebSockets / gRPC streaming na die handshake

Baie edge rate-limiters inspekteer slegs die initial HTTP request. Sodra die verbinding opgradeer na WebSocket (HTTP 101) of gRPC bidirectional streaming, bypass opvolgende boodskappe dikwels die request-per-second counters omdat dit nie meer aparte HTTP requests is nie. Cloudflare se eie docs merk op dat slegs die initial upgrade request onderhewig is aan WAF/rate-limiting rules; frames wat daarna gestuur word, is ondoorsigbaar.

Praktiese 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

As die login/OTP-endpoint beide HTTP- en WebSocket/gRPC-variante blootstel, stel eers die opgegradeerde kanaal vas en spuit dan kodes binne daardie enkele verbinding om per-request throttles te ontduik.

Benutting van CDN PoP‑sharded counters

Sommige CDNs shard rate-limit counters per data center/PoP in plaas van globaal. Cloudflare stel uitdruklik dat counters nie oor data centers gedeel word nie. Deur versoeke deur egress nodes in baie streke te roteer (residential proxy pools, anycast VPNs, of cloud VMs wat aan verskillende kontinente vasgemaak is), vermenigvuldig jy die toegelate deurset: elke PoP handhaaf ’n onafhanklike bucket vir dieselfde key.

Vinnige en rowwe uitleg wat open proxies gebruik (voorbeeld met proxychains + ’n 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

Maak seker die limiter key is nie per-rekening nie; anders roteer ook user IDs / session tokens.

Gereedskap

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing tool wat header randomisation, chunked word-lists en round-robin proxy rotation ondersteun.
  • https://github.com/ustayready/fireprox: Skep outomaties weggooibare AWS API Gateway endpoints sodat elke versoek vanaf ’n ander IP-adres afkomstig is – perfek om IP-based throttling te omseil.
  • Burp Suite – IPRotate + extension: Gebruik ’n poel SOCKS/HTTP proxies (of AWS API Gateway) om die bron-IP deursigtig te roteer tydens Intruder en Turbo Intruder aanvalle.
  • Turbo Intruder (BApp): Hoë-prestasie attack engine wat HTTP/2 multiplexing ondersteun; stel requestsPerConnection op 100-1000 om honderde versoeke in ’n enkele verbinding saam te vat.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks