Bypass della limitazione delle richieste

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Tecniche per bypassare la limitazione delle richieste

Esplorare endpoint simili

Si dovrebbero tentare brute force attacks su varianti dell’endpoint target, come /api/v3/sign-up, includendo alternative come /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up ecc.

Inserire caratteri vuoti nel codice o nei parametri

Inserire byte vuoti come %00, %0d%0a, %0d, %0a, %09, %0C, %20 nel codice o nei parametri può essere una strategia utile. Per esempio, modificare un parametro in code=1234%0a permette di estendere i tentativi tramite variazioni nell’input, come aggiungere caratteri di nuova riga a un indirizzo email per aggirare i limiti di tentativi.

Manipolare l’origine IP tramite header

Modificare gli header per alterare l’origine IP percepita può aiutare a evitare la limitazione basata su IP. Header come X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, incluso l’uso di più istanze di X-Forwarded-For, possono essere regolati per simulare richieste da indirizzi IP diversi.

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

Modificare altri header

È consigliabile alterare altri request header come user-agent e cookies, poiché questi possono essere utilizzati per identificare e tracciare i pattern di richiesta. Cambiare questi header può prevenire il riconoscimento e il tracciamento delle attività del richiedente.

Sfruttare il comportamento degli API gateway

Alcuni API gateway sono configurati per applicare il rate limiting in base alla combinazione di endpoint e parametri. Variando i valori dei parametri o aggiungendo parametri non significativi alla richiesta, è possibile eludere la logica di rate-limiting del gateway, facendo apparire ogni richiesta come unica. Ad esempio /resetpwd?someparam=1.

Accedere al proprio account prima di ogni tentativo

Effettuare il login in un account prima di ogni tentativo, o a ogni serie di tentativi, potrebbe azzerare il contatore del rate limit. Questo è particolarmente utile quando si testano le funzionalità di login. Utilizzare una Pitchfork attack in strumenti come Burp Suite, ruotando le credenziali ogni pochi tentativi e assicurandosi che ‘follow redirects’ sia abilitato, può riavviare efficacemente i contatori del rate limit.

Utilizzo di reti di proxy

Distribuire una rete di proxy per ripartire le richieste su più indirizzi IP può bypassare efficacemente i rate limit basati su IP. Instradando il traffico attraverso diversi proxy, ogni richiesta sembra provenire da una fonte diversa, riducendo l’efficacia del rate limit.

Suddividere l’attacco su account o sessioni differenti

Se il sistema target applica rate limit per account o per sessione, distribuire l’attacco o il test su più account o sessioni può aiutare a evitare il rilevamento. Questo approccio richiede la gestione di più identità o token di sessione, ma può distribuire efficacemente il carico per rimanere entro i limiti consentiti.

Continua a provare

Nota che anche se è presente un rate limit dovresti provare a verificare se la risposta è diversa quando viene inviato l’OTP valido. In this post, il bug hunter ha scoperto che anche se un rate limit viene attivato dopo 20 tentativi non riusciti rispondendo con 401, se veniva inviato quello valido si riceveva una risposta 200.

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

Le implementazioni moderne di rate–limiter frequentemente conteggiano TCP connections (or even individual HTTP/1.1 requests) invece del number of HTTP/2 streams contenuti in una connessione. Quando la stessa connessione TLS viene riutilizzata, un attacker può aprire centinaia di stream paralleli, ciascuno con una request separata, mentre il gateway sottrae dalla quota solo 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

Se il limiter protegge solo /verify ma non /api/v2/verify, puoi anche combinare path confusion con HTTP/2 multiplexing per un brute-forcing di OTP o di credenziali a velocità estremamente elevate.

🐾 Suggerimento: PortSwigger’s Turbo Intruder supporta HTTP/2 e ti permette di affinare maxConcurrentConnections e requestsPerConnection per automatizzare questo attacco.

GraphQL aliases & batched operations

GraphQL permette al client di inviare diverse queries o mutations logicamente indipendenti in una singola request prefissandole con aliases. Poiché il server esegue ogni alias ma il rate-limiter spesso conta solo una request, questo rappresenta un bypass affidabile per login o 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 …
}

Guarda la risposta: esattamente un alias restituirà 200 OK quando il codice corretto viene inviato, mentre gli altri sono rate-limited.

La tecnica è stata resa popolare dalla ricerca di PortSwigger su “GraphQL batching & aliases” nel 2023 ed è stata responsabile di molti recenti bug-bounty payouts.

Abuso di batch o bulk REST endpoints

Alcune API espongono helper endpoints come /v2/batch o accettano un array di oggetti nel corpo della richiesta. Se il limiter è posizionato solo davanti ai legacy endpoints, raggruppare più operazioni all’interno di una singola bulk request può aggirare completamente la protezione.

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

Temporizzazione della sliding-window

Un classico limitatore token-bucket o leaky-bucket si azzera su un confine temporale fisso (ad esempio, ogni minuto). Se la finestra è nota (ad esempio tramite messaggi di errore come X-RateLimit-Reset: 27), invia il numero massimo consentito di richieste poco prima che il bucket si azzeri, poi invia immediatamente un altro burst completo.

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

Questa semplice ottimizzazione può più che raddoppiare il throughput senza toccare altre tecniche di bypass.

Aggiornamento a WebSockets / gRPC streaming dopo l’handshake

Molti rate-limiters a livello edge ispezionano solo la richiesta HTTP iniziale. Una volta che la connessione viene aggiornata a WebSocket (HTTP 101) o a gRPC bidirectional streaming, i messaggi successivi spesso bypassano i contatori delle richieste al secondo perché non sono più richieste HTTP separate. La documentazione di Cloudflare stessa segnala che solo la richiesta di upgrade iniziale è soggetta alle regole del WAF/rate-limiting; i frame inviati successivamente sono opachi.

Flusso di lavoro pratico:

# 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

Se l’endpoint di login/OTP espone sia varianti HTTP che WebSocket/gRPC, stabilisci prima il canale aggiornato e poi invia in modalità spray i codici all’interno di quella singola connessione per eludere il throttling per richiesta.

Sfruttare contatori shardati per PoP delle CDN

Alcune CDN shardano i contatori di rate-limit per data center/PoP invece che globalmente. Cloudflare afferma esplicitamente che i contatori non sono condivisi tra i data center. Instradando le richieste attraverso nodi di egress in molte regioni (residential proxy pools, anycast VPNs, o cloud VMs assegnate a continenti diversi), moltiplichi la capacità consentita: ogni PoP mantiene un bucket indipendente per la stessa chiave.

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

Assicurati che la limiter key non sia per-account; altrimenti ruota anche user IDs / session tokens.

Strumenti

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Strumento di Fuzzing che supporta header randomisation, chunked word-lists e round-robin proxy rotation.
  • https://github.com/ustayready/fireprox: Crea automaticamente endpoint usa e getta di AWS API Gateway in modo che ogni richiesta provenga da un indirizzo IP diverso — perfetto per aggirare il throttling basato su IP.
  • Burp Suite – IPRotate + extension: Usa un pool di proxy SOCKS/HTTP (o AWS API Gateway) per ruotare l’IP sorgente in modo trasparente durante gli attacchi Intruder e Turbo Intruder.
  • Turbo Intruder (BApp): Motore di attacco ad alte prestazioni che supporta HTTP/2 multiplexing; regola requestsPerConnection su 100-1000 per comprimere centinaia di richieste in una singola connessione.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks