Omijanie ograniczeń liczby żądań

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Techniki omijania limitów

Badanie podobnych endpointów

Należy próbować przeprowadzać brute force attacks na wariantach docelowego endpointu, takich jak /api/v3/sign-up, włączając alternatywy takie jak /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up itd.

Wstawianie pustych znaków w kodzie lub parametrach

Wstawianie pustych bajtów, takich jak %00, %0d%0a, %0d, %0a, %09, %0C, %20, w kodzie lub parametrach może być użyteczną strategią. Na przykład zmiana parametru na code=1234%0a pozwala rozszerzyć próby przez wariacje w danych wejściowych, np. dodanie znaków nowej linii do adresu e-mail w celu obejścia ograniczeń liczby prób.

Manipulowanie pochodzeniem IP przez nagłówki

Modyfikowanie nagłówków w celu zmiany postrzeganego pochodzenia IP może pomóc w ominięciu ograniczeń opartych na IP. Nagłówki takie jak X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, w tym użycie wielu instancji X-Forwarded-For, mogą być modyfikowane, aby zasymulować żądania z różnych adresów IP.

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

Zmiana innych nagłówków

Zaleca się modyfikowanie innych nagłówków żądania, takich jak user-agent i cookies, ponieważ mogą być używane do identyfikacji i śledzenia wzorców żądań. Zmiana tych nagłówków może uniemożliwić rozpoznanie i śledzenie działań żądającego.

Wykorzystanie zachowania API gateways

Niektóre API gateways są skonfigurowane tak, aby stosować rate limiting na podstawie kombinacji endpointu i parametrów. Zmienianie wartości parametrów lub dodawanie do żądania parametrów bez znaczenia może obejść logikę rate-limiting gateweya, sprawiając, że każde żądanie będzie wyglądać na unikatowe. Na przykład /resetpwd?someparam=1.

Logowanie się na konto przed każdą próbą

Logowanie się na konto przed każdą próbą lub przed każdym zestawem prób może zresetować licznik rate limit. Jest to szczególnie przydatne przy testowaniu funkcji logowania. Wykorzystanie Pitchfork attack w narzędziach takich jak Burp Suite, aby rotować poświadczenia co kilka prób oraz upewnienie się, że opcja follow redirects jest zaznaczona, może skutecznie ponownie uruchomić liczniki rate limit.

Wykorzystanie proxy networks

Rozmieszczenie sieci proxy w celu rozdzielenia żądań pomiędzy wiele adresów IP może skutecznie obejść IP-based rate limits. Przekierowując ruch przez różne proxy, każde żądanie wygląda, jakby pochodziło z innego źródła, rozmywając skuteczność rate limitu.

Rozdzielenie ataku na różne konta lub sesje

Jeśli system docelowy stosuje rate limits na poziomie konta (per-account) lub sesji (per-session), rozdzielenie ataku lub testu na wiele kont lub sesji może pomóc w uniknięciu wykrycia. Podejście to wymaga zarządzania wieloma tożsamościami lub session tokens, ale może skutecznie rozłożyć obciążenie, żeby pozostać w dozwolonych limitach.

Próbuj dalej

Zauważ, że nawet jeśli rate limit jest aktywny, warto sprawdzić, czy odpowiedź będzie inna po wysłaniu prawidłowego OTP. W tym poście, bug hunter odkrył, że nawet jeśli po 20 nieudanych próbach rate limit jest wyzwalany i serwer odpowiada 401, to przy wysłaniu prawidłowej odpowiedzi otrzymano 200.

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

Współczesne implementacje rate–limiterów często zliczają TCP connections (a nawet pojedyncze HTTP/1.1 requests) zamiast number of HTTP/2 streams zawartych w połączeniu. Gdy to samo TLS connection jest ponownie używane, atakujący może otworzyć setki równoległych streams, z których każdy niesie oddzielne żądanie, podczas gdy gateway odlicza tylko one request z przydziału.

# 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

Jeśli limiter chroni tylko /verify, a nie /api/v2/verify, możesz też połączyć path confusion z HTTP/2 multiplexing, aby przeprowadzić niezwykle szybkie brute-forcing OTP lub credential brute-forcing.

🐾 Tip: PortSwigger’s Turbo Intruder obsługuje HTTP/2 i pozwala dostroić maxConcurrentConnections i requestsPerConnection, aby zautomatyzować ten atak.

GraphQL aliasy & operacje wsadowe

GraphQL pozwala klientowi wysłać kilka logicznie niezależnych zapytań lub mutacji w jednym żądaniu, poprzedzając je aliasami. Ponieważ serwer wykonuje każdy alias, a rate-limiter często zlicza tylko jedno żądanie, jest to niezawodny bypass throttlingu dla loginu lub password-reset.

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

Spójrz na odpowiedź: dokładnie jeden alias zwróci 200 OK, gdy trafi właściwy kod, a pozostałe będą rate-limited.

Technika została spopularyzowana przez badania PortSwiggera dotyczące “GraphQL batching & aliases” w 2023 roku i była odpowiedzialna za wiele ostatnich wypłat bug-bounty.

Nadużycie batch lub bulk REST endpoints

Niektóre API udostępniają pomocnicze endpoints takie jak /v2/batch lub akceptują array of objects w ciele żądania. Jeśli limiter jest umieszczony tylko przed legacy endpoints, opakowanie wielu operacji w jedno bulk request może całkowicie obejść ochronę.

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

Czasowanie sliding-window

Klasyczny token-bucket lub leaky-bucket limiter resetuje się na ustalonej granicy czasowej (na przykład co minutę). Jeśli okno jest znane (np. poprzez komunikaty o błędach takie jak X-RateLimit-Reset: 27), wyślij maksymalną dozwoloną liczbę żądań tuż przed tym, jak bucket się zresetuje, a następnie natychmiast wyślij kolejny pełny burst.

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

Ta prosta optymalizacja może więcej niż podwoić przepustowość bez ingerencji w żadną inną bypass technique.

Uaktualnienie do WebSockets / gRPC streaming po handshake

Wiele edge rate-limiters sprawdza tylko initial HTTP request. Gdy połączenie zostanie zaktualizowane do WebSocket (HTTP 101) lub gRPC bidirectional streaming, kolejne wiadomości często omijają request-per-second counters, ponieważ nie są już osobnymi HTTP requests. Dokumentacja Cloudflare’s zauważa, że tylko początkowe żądanie upgrade jest objęte WAF/rate-limiting rules; frames wysyłane później są opaque.

Praktyczny 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

Jeśli endpoint login/OTP udostępnia zarówno warianty HTTP, jak i WebSocket/gRPC, najpierw nawiąż zaktualizowany kanał, a następnie spray codes w ramach tego pojedynczego połączenia, aby obejść per-request throttles.

Wykorzystywanie CDN PoP‑sharded counters

Niektóre CDNs dzielą liczniki rate-limit per data center/PoP zamiast globalnie. Cloudflare wyraźnie stwierdza, że liczniki nie są współdzielone między centrami danych. Przez kierowanie żądań przez egress nodes w wielu regionach (residential proxy pools, anycast VPNs lub cloud VMs przypięte do różnych kontynentów) mnożysz dozwoloną przepustowość: każdy PoP utrzymuje niezależny bucket dla tego samego klucza.

Szybki i prowizoryczny schemat z użyciem open proxies (przykład z proxychains + listą rotującą krajów):

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

Upewnij się, że klucz limitera nie jest przypisany na konto; w przeciwnym razie rotuj także identyfikatory użytkowników / tokeny sesji.

Tools

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Fuzzing tool obsługujący header randomisation, chunked word-lists i round-robin proxy rotation.
  • https://github.com/ustayready/fireprox: Automatycznie tworzy jednorazowe AWS API Gateway endpoints, dzięki czemu każde żądanie pochodzi z innego adresu IP — idealne do pokonania IP-based throttling.
  • Burp Suite – IPRotate + extension: Używa puli SOCKS/HTTP proxies (lub AWS API Gateway) do rotacji źródłowego adresu IP w sposób przeźroczysty podczas Intruder i Turbo Intruder attacks.
  • Turbo Intruder (BApp): Wysokowydajny silnik ataków z obsługą HTTP/2 multiplexing; ustaw requestsPerConnection na 100–1000, aby zwinąć setki żądań w jedno połączenie.

References

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks