Rate Limit Bypass

Reading time: 7 minutes

Techniken zum Umgehen von Ratenbegrenzungen

Erforschen ähnlicher Endpunkte

Es sollten Versuche unternommen werden, Brute-Force-Angriffe auf Variationen des angestrebten Endpunkts durchzuführen, wie z.B. /api/v3/sign-up, einschließlich Alternativen wie /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up usw.

Einfügen von Leerzeichen in Code oder Parameter

Das Einfügen von Leerbytes wie %00, %0d%0a, %0d, %0a, %09, %0C, %20 in Code oder Parameter kann eine nützliche Strategie sein. Zum Beispiel ermöglicht die Anpassung eines Parameters auf code=1234%0a das Erweitern von Versuchen durch Variationen in der Eingabe, wie das Hinzufügen von Zeilenumbrüchen zu einer E-Mail-Adresse, um Versuchsbeschränkungen zu umgehen.

Manipulation des IP-Ursprungs über Header

Das Ändern von Headern, um den wahrgenommenen IP-Ursprung zu verändern, kann helfen, IP-basierte Ratenbegrenzungen 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 verschiedenen 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, andere Anfrage-Header wie den User-Agent und Cookies zu ändern, da diese ebenfalls zur Identifizierung und Verfolgung von Anfrage-Mustern verwendet werden können. Das Ändern dieser Header kann die Erkennung und Verfolgung der Aktivitäten des Anfragenden verhindern.

Ausnutzen des Verhaltens von API-Gateways

Einige API-Gateways sind so konfiguriert, dass sie die Ratenbegrenzung basierend auf der Kombination von Endpunkt und Parametern anwenden. Durch Variieren der Parameterwerte oder Hinzufügen von unwesentlichen Parametern zur Anfrage ist es möglich, die Ratenbegrenzungslogik des Gateways zu umgehen, sodass jede Anfrage einzigartig erscheint. Zum Beispiel /resetpwd?someparam=1.

Anmeldung in Ihrem Konto vor jedem Versuch

Die Anmeldung in einem Konto vor jedem Versuch oder jeder Versuchsreihe könnte den Zähler für die Ratenbegrenzung zurücksetzen. Dies ist besonders nützlich, wenn Login-Funktionalitäten getestet werden. Die Nutzung eines Pitchfork-Angriffs in Tools wie Burp Suite, um die Anmeldeinformationen alle paar Versuche zu rotieren und sicherzustellen, dass Weiterleitungen markiert sind, kann die Zähler für die Ratenbegrenzung effektiv zurücksetzen.

Nutzung von Proxy-Netzwerken

Der Einsatz eines Netzwerks von Proxys zur Verteilung der Anfragen über mehrere IP-Adressen kann IP-basierte Ratenbegrenzungen effektiv umgehen. Durch das Routen des Verkehrs über verschiedene Proxys scheint jede Anfrage von einer anderen Quelle zu stammen, wodurch die Effektivität der Ratenbegrenzung verringert wird.

Aufteilen des Angriffs über verschiedene Konten oder Sitzungen

Wenn das Zielsystem Ratenbegrenzungen auf Basis von Konto oder Sitzung anwendet, kann das Verteilen des Angriffs oder Tests über mehrere Konten oder Sitzungen helfen, eine Erkennung zu vermeiden. Dieser Ansatz erfordert die Verwaltung mehrerer Identitäten oder Sitzungstoken, kann jedoch die Last effektiv verteilen, um innerhalb der zulässigen Grenzen zu bleiben.

Weiter versuchen

Beachten Sie, dass Sie auch dann versuchen sollten, zu sehen, ob die Antwort unterschiedlich ist, wenn die gültige OTP gesendet wird, selbst wenn eine Ratenbegrenzung besteht. In diesem Beitrag entdeckte der Bug-Jäger, dass selbst wenn eine Ratenbegrenzung nach 20 erfolglosen Versuchen durch eine Antwort mit 401 ausgelöst wird, eine 200-Antwort empfangen wurde, wenn die gültige gesendet wurde.

Missbrauch von HTTP/2-Multiplexing & Anfrage-Pipelining (2023-2025)

Moderne Implementierungen von Ratenbegrenzern zählen häufig TCP-Verbindungen (oder sogar einzelne HTTP/1.1-Anfragen) anstelle der Anzahl der HTTP/2-Streams, die eine Verbindung enthält. Wenn dieselbe TLS-Verbindung wiederverwendet wird, kann ein Angreifer Hunderte paralleler Streams öffnen, von denen jeder eine separate Anfrage trägt, während das Gateway nur eine Anfrage 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 schützt, aber nicht /api/v2/verify, können Sie auch Path-Verwirrung mit HTTP/2-Multiplexing für extrem schnelle OTP- oder Anmeldeinformationen-Brute-Forcing kombinieren.

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

GraphQL-Alias und gebündelte Operationen

GraphQL ermöglicht es dem Client, mehrere logisch unabhängige Abfragen oder Mutationen in einer einzigen Anfrage zu senden, indem sie mit Alias vorangestellt werden. Da der Server jeden Alias ausführt, der Rate-Limiter jedoch oft nur eine Anfrage zählt, ist dies ein zuverlässiger Umgehungsmechanismus für das Drosseln von Anmeldungen oder Passwortzurücksetzungen.

mutation bruteForceOTP {
a: verify(code:"111111") { token }
b: verify(code:"222222") { token }
c: verify(code:"333333") { token }
# … add up to dozens of aliases …
}

Schau dir die Antwort an: genau ein Alias wird 200 OK zurückgeben, wenn der korrekte Code getroffen wird, während die anderen einer Rate-Limitierung unterliegen.

Die Technik wurde durch die Forschung von PortSwigger zu „GraphQL-Batching & Aliases“ im Jahr 2023 populär und war verantwortlich für viele kürzliche Bug-Bounty-Auszahlungen.

Missbrauch von Batch oder Bulk REST-Endpunkten

Einige APIs bieten Hilfsendpunkte wie /v2/batch an oder akzeptieren ein Array von Objekten im Anfragekörper. Wenn der Limiter nur vor den Legacy-Endpunkten platziert ist, kann das Einpacken mehrerer Operationen in eine einzige 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 the sliding-window

Ein klassischer Token-Bucket- oder Leaky-Bucket-Limiter setzt zurück an einer festen Zeitgrenze (zum Beispiel jede Minute). Wenn das Zeitfenster bekannt ist (z. B. durch Fehlermeldungen wie X-RateLimit-Reset: 27), sende die maximal erlaubte Anzahl von Anfragen kurz bevor der Bucket zurückgesetzt wird, und sende dann sofort einen weiteren vollen Burst.

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

Diese einfache Optimierung kann Ihre Durchsatzrate mehr als verdoppeln, ohne andere Bypass-Techniken zu berühren.

Tools

• https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing-Tool, das Header-Randomisierung, chunked Wortlisten und Round-Robin-Proxy-Rotation unterstützt.
• https://github.com/ustayready/fireprox: Erstellt automatisch disposable AWS API Gateway-Endpunkte, sodass jede Anfrage von einer anderen IP-Adresse stammt – perfekt, um IP-basiertes Drosseln zu überwinden.
• Burp Suite – IPRotate + Erweiterung: Verwendet einen Pool von SOCKS/HTTP-Proxys (oder AWS API Gateway), um die Quell-IP während Intruder und Turbo Intruder Angriffe transparent zu rotieren.
• Turbo Intruder (BApp): Hochleistungsangriffs-Engine, die HTTP/2-Multiplexing unterstützt; stellen Sie requestsPerConnection auf 100-1000 ein, um Hunderte von Anfragen in einer einzigen Verbindung zusammenzufassen.

References

• PortSwigger Research – “Bypassing rate limits with GraphQL aliasing” (2023) https://portswigger.net/research/graphql-authorization-bypass
• PortSwigger Research – “HTTP/2: The Sequel is Always Worse” (Abschnitt Connection-based throttling) (2024) https://portswigger.net/research/http2