Rate Limit Bypass

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Rate limit bypass techniques

Ähnliche Endpunkte erkunden

Es sollten Versuche unternommen werden, brute force attacks gegen Variationen des Zielendpunkts durchzuführen, wie /api/v3/sign-up, einschließlich Alternativen wie /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up usw.

Einfügen von Blank-Zeichen in Code oder Parametern

Das Einfügen von leeren Bytes wie %00, %0d%0a, %0d, %0a, %09, %0C, %20 in Code oder Parameter kann eine nützliche Strategie sein. Zum Beispiel erlaubt das Anpassen eines Parameters zu code=1234%0a das Ausweiten von Versuchen durch Variationen in der Eingabe, etwa durch Hinzufügen von Newline-Zeichen zu einer E-Mail-Adresse, um Beschränkungen der Versuche zu umgehen.

Manipulation des IP-Ursprungs über Header

Das Modifizieren von Headern, um die wahrgenommene IP-Herkunft zu ändern, kann helfen, IP-based rate limiting zu umgehen. Header wie X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, einschließlich der Verwendung mehrerer Instanzen von X-Forwarded-For, können angepasst werden, um Anfragen von unterschiedlichen IPs zu simulieren.

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

Ändern anderer Header

Es wird empfohlen, weitere Request-Header wie user-agent und cookies zu ändern, da diese ebenfalls zur Identifikation und Nachverfolgung von Anfrage-Mustern verwendet werden können. Durch das Ändern dieser Header lässt sich die Erkennung und Verfolgung der Aktivitäten des Anfragenden verhindern.

Ausnutzung des Verhaltens von API Gateways

Einige API Gateways sind so konfiguriert, dass sie rate limiting basierend auf der Kombination aus Endpoint und Parametern anwenden. Durch Variieren der Parameterwerte oder Hinzufügen nicht-signifikanter Parameter zur Anfrage lässt sich die Rate-Limiting-Logik des Gateways umgehen, sodass jede Anfrage einzigartig erscheint. Zum Beispiel /resetpwd?someparam=1.

Vor jedem Versuch in Ihr Konto einloggen

Ein Einloggen in ein Konto vor jedem Versuch oder vor jeder Versuchsreihe kann den Rate-Limit-Zähler zurücksetzen. Das ist besonders nützlich beim Testen von Login-Funktionalitäten. Der Einsatz einer Pitchfork attack in Tools wie Burp Suite, um nach ein paar Versuchen die credentials zu rotieren, und das Sicherstellen, dass ‘follow redirects’ aktiviert ist, kann Rate-Limit-Zähler effektiv neu starten.

Einsatz von Proxy-Netzwerken

Der Einsatz eines Netzwerks von Proxies, um Anfragen über mehrere IP-Adressen zu verteilen, kann IP-basierte rate limits effektiv umgehen. Indem der Traffic über verschiedene Proxies geleitet wird, scheint jede Anfrage von einer anderen Quelle zu stammen, wodurch die Wirksamkeit des Rate-Limits verwässert wird.

Aufteilen des Angriffs auf verschiedene Accounts oder Sessions

Wenn das Zielsystem rate limits pro Account oder pro Session anwendet, kann das Verteilen des Angriffs oder Tests auf mehrere Accounts oder Sessions helfen, eine Entdeckung zu vermeiden. Dieser Ansatz erfordert das Management mehrerer Identitäten oder Session-Tokens, kann aber die Last effektiv verteilen, um innerhalb der erlaubten Limits zu bleiben.

Weitermachen

Beachte, dass du selbst bei vorhandenem rate limit prüfen solltest, ob die Antwort anders ist, wenn der gültige OTP gesendet wird. In this post, entdeckte der Bug-Hunter, dass selbst wenn nach 20 erfolglosen Versuchen ein rate limit ausgelöst wurde und mit 401 geantwortet wurde, beim Senden des gültigen Codes eine 200-Antwort zurückkam.

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

Moderne rate–limiter-Implementierungen zählen häufig TCP connections (oder sogar einzelne HTTP/1.1 requests) anstatt der number of HTTP/2 streams, die eine Connection enthält. Wenn dieselbe TLS connection wiederverwendet wird, kann ein Angreifer Hunderte parallele Streams öffnen, wobei jeder eine separate Anfrage enthält, während das Gateway nur einen Request vom Kontingent abzieht.

# 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

Wenn der Limiter nur /verify, aber nicht /api/v2/verify schützt, kannst du path confusion mit HTTP/2-Multiplexing kombinieren, um extrem schnelle OTP- oder credential brute-forcing-Angriffe durchzuführen.

🐾 Tipp: PortSwigger’s Turbo Intruder unterstützt HTTP/2 und ermöglicht es dir, maxConcurrentConnections und requestsPerConnection fein abzustimmen, um diesen Angriff zu automatisieren.

GraphQL aliases & gebündelte Operationen

GraphQL erlaubt dem Client, mehrere logisch unabhängige queries oder mutations in einer einzigen request zu senden, indem er sie mit aliases versieht. Da der Server jeden alias ausführt, der rate-limiter jedoch oft nur eine request zählt, ist dies ein zuverlässiger Bypass gegen login- oder 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 …
}

Sieh dir die Antwort an: genau ein alias wird 200 OK zurückgeben, wenn der richtige Code abgefragt wird, während die anderen rate-limited sind.

Die Technik wurde durch PortSwigger’s Forschung zu “GraphQL batching & aliases” im Jahr 2023 popularisiert und ist für viele kürzliche bug-bounty payouts verantwortlich.

Missbrauch von batch oder bulk REST-Endpunkten

Einige APIs stellen Hilfsendpunkte wie /v2/batch bereit oder akzeptieren einen array of objects im Request-Body. Wenn der limiter nur vor den legacy Endpunkten platziert ist, kann das Bündeln mehrerer Operationen in einer einzigen bulk-Anfrage den Schutz vollständig umgehen.

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

Timing des sliding-window

Ein klassischer token-bucket- oder leaky-bucket-Limiter wird an einer festen Zeitgrenze zurückgesetzt (zum Beispiel jede Minute). Wenn das Fenster bekannt ist (z. B. via Fehlermeldungen wie X-RateLimit-Reset: 27), feuere die maximal erlaubte Anzahl an Requests kurz bevor der Bucket zurückgesetzt wird, und feuere dann sofort einen weiteren vollen Burst.

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

Diese einfache Optimierung kann deinen Durchsatz mehr als verdoppeln, ohne irgendeine andere bypass technique zu berühren.

Upgrade auf WebSockets / gRPC streaming nach dem handshake

Viele edge rate-limiters prüfen nur die initial HTTP request. Sobald die Verbindung auf WebSocket (HTTP 101) oder gRPC bidirectional streaming umgestellt ist, umgehen nachfolgende Nachrichten häufig die request-per-second counters, weil sie nicht mehr als separate HTTP requests behandelt werden. Cloudflare’s own docs weisen darauf hin, dass nur die initial upgrade request den WAF/rate-limiting rules unterliegt; frames, die danach gesendet werden, werden in der Regel nicht mehr geprüft.

Praktischer Ablauf:

# 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

If the login/OTP endpoint exposes both HTTP and WebSocket/gRPC variants, establish the upgraded channel first and then spray codes within that single connection to evade per-request throttles.

Ausnutzen von CDN PoP‑geshardeten Zählern

Einige CDNs shard rate-limit counters pro Rechenzentrum/PoP statt global. Cloudflare gibt ausdrücklich an, dass Zähler nicht zwischen Rechenzentren geteilt werden. Durch das Routen von Requests über Egress‑Knoten in vielen Regionen (residential proxy pools, anycast VPNs oder cloud VMs, die auf verschiedene Kontinente gepinnt sind) vervielfachst du den erlaubten Durchsatz: jedes PoP pflegt einen unabhängigen bucket für denselben key.

Schnelles, pragmatisches Setup mit open proxies (Beispiel mit proxychains + einer nach Ländern rotierenden Liste):

for p in $(cat proxies.txt); do
HTTPS_PROXY=$p curl -s -X POST https://target/api/login -d @payload.json &
done
wait

Stelle sicher, dass der Limiter-Key nicht pro Account vergeben wird; andernfalls rotiere zusätzlich user IDs / session tokens.

Werkzeuge

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing-Tool, das Header-Randomisierung, chunked word-lists und Round-Robin-Proxy-Rotation unterstützt.
  • https://github.com/ustayready/fireprox: Erzeugt automatisch disposable AWS API Gateway-Endpunkte, sodass jede Anfrage von einer anderen IP-Adresse stammt – ideal, um IP-basiertes Throttling zu umgehen.
  • Burp Suite – IPRotate + extension: Verwendet einen Pool von SOCKS/HTTP-Proxys (oder AWS API Gateway), um die Quell-IP während Intruder- und Turbo Intruder-Angriffen transparent zu rotieren.
  • Turbo Intruder (BApp): Hochleistungs-Angriffsmotor mit Unterstützung für HTTP/2-Multiplexing; passe requestsPerConnection auf 100–1000 an, um Hunderte von Requests in eine einzige Verbindung zusammenzufassen.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks