# Rate Limit Bypass {{#include ../banners/hacktricks-training.md}} ## Techniki omijania limitów ### Badanie podobnych punktów końcowych Należy podjąć próby przeprowadzenia ataków brute force na warianty docelowego punktu końcowego, takie jak `/api/v3/sign-up`, w tym alternatywy takie jak `/Sing-up`, `/SignUp`, `/singup`, `/api/v1/sign-up`, `/api/sign-up` itd. ### Wprowadzanie pustych znaków w kodzie lub parametrach Wstawianie pustych bajtów, takich jak `%00`, `%0d%0a`, `%0d`, `%0a`, `%09`, `%0C`, `%20` do kodu lub parametrów może być użyteczną strategią. Na przykład, dostosowanie parametru do `code=1234%0a` pozwala na rozszerzenie prób poprzez wariacje w wejściu, takie jak dodawanie znaków nowej linii do adresu e-mail, aby obejść ograniczenia prób. ### Manipulowanie pochodzeniem IP za pomocą nagłówków Modyfikacja nagłówków w celu zmiany postrzeganego pochodzenia IP może pomóc w ominięciu limitów 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ć dostosowane w celu symulacji żądań z różnych adresów IP. ```bash 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ę modyfikację innych nagłówków żądania, takich jak user-agent i ciasteczka, ponieważ mogą one być również używane do identyfikacji i śledzenia wzorców żądań. Zmiana tych nagłówków może zapobiec rozpoznawaniu i śledzeniu działań osoby składającej żądanie. ### Wykorzystanie Zachowania Bramy API Niektóre bramy API są skonfigurowane do stosowania limitów na podstawie kombinacji punktu końcowego i parametrów. Zmienianie wartości parametrów lub dodawanie nieistotnych parametrów do żądania może umożliwić obejście logiki limitowania bramy, sprawiając, że każde żądanie wydaje się unikalne. Na przykład `/resetpwd?someparam=1`. ### Logowanie się do swojego konta przed każdym podejściem Logowanie się do konta przed każdym podejściem lub każdą serią prób może zresetować licznik limitu. Jest to szczególnie przydatne podczas testowania funkcji logowania. Wykorzystanie ataku Pitchfork w narzędziach takich jak Burp Suite, aby rotować dane uwierzytelniające co kilka prób i upewnić się, że przekierowania są oznaczone, może skutecznie zrestartować liczniki limitu. ### Wykorzystanie Sieci Proxy Wdrożenie sieci proxy do rozdzielania żądań na wiele adresów IP może skutecznie obejść limity oparte na IP. Przez kierowanie ruchu przez różne proxy, każde żądanie wydaje się pochodzić z innego źródła, osłabiając skuteczność limitu. ### Rozdzielanie Ataku na Różne Konta lub Sesje Jeśli system docelowy stosuje limity na poziomie konta lub sesji, 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 tokenami sesji, ale może skutecznie rozłożyć obciążenie, aby pozostać w dozwolonych limitach. ### Kontynuuj Próby Zauważ, że nawet jeśli limit jest wprowadzony, powinieneś spróbować zobaczyć, czy odpowiedź jest inna, gdy wysłany jest ważny OTP. W [**tym poście**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732), łowca błędów odkrył, że nawet jeśli limit jest wyzwolony po 20 nieudanych próbach, odpowiadając z 401, jeśli wysłano ważny, otrzymano odpowiedź 200. --- ### Wykorzystywanie multiplexingu HTTP/2 i pipeliningu żądań (2023-2025) Nowoczesne implementacje limitów często liczą **połączenia TCP** (lub nawet pojedyncze żądania HTTP/1.1) zamiast *liczby strumieni HTTP/2*, które zawiera połączenie. Gdy to samo połączenie TLS jest ponownie używane, atakujący może otworzyć setki równoległych strumieni, z których każdy niesie osobne żądanie, podczas gdy brama odejmuje *jedno* żądanie od limitu. ```bash # 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`, ale nie `/api/v2/verify`, możesz również połączyć **confusion path** z multiplexingiem HTTP/2 dla *ekstremalnie* szybkiego brute-forcingu OTP lub poświadczeń. > 🐾 **Wskazówka:** PortSwigger’s [Turbo Intruder](https://portswigger.net/research/turbo-intruder) obsługuje HTTP/2 i pozwala na precyzyjne dostosowanie `maxConcurrentConnections` oraz `requestsPerConnection`, aby zautomatyzować ten atak. ### Aliasy GraphQL i operacje zbiorcze GraphQL pozwala klientowi na wysyłanie **kilku logicznie niezależnych zapytań lub mutacji w jednym żądaniu** poprzez ich prefiksowanie *aliasami*. Ponieważ serwer wykonuje każdy alias, ale limiter często liczy tylko *jedno* żądanie, jest to niezawodne obejście dla ograniczeń logowania lub resetowania hasła. ```graphql mutation bruteForceOTP { a: verify(code:"111111") { token } b: verify(code:"222222") { token } c: verify(code:"333333") { token } # … add up to dozens of aliases … } ``` Zobacz odpowiedź: dokładnie jeden alias zwróci 200 OK, gdy poprawny kod zostanie trafiony, podczas gdy inne są ograniczone przez limit. Technika ta została spopularyzowana przez badania PortSwigger na temat „GraphQL batching & aliases” w 2023 roku i była odpowiedzialna za wiele ostatnich wypłat w programach bug-bounty. ### Nadużycie *batch* lub *bulk* punktów końcowych REST Niektóre API udostępniają pomocnicze punkty końcowe, takie jak `/v2/batch` lub akceptują **tablicę obiektów** w ciele żądania. Jeśli limiter jest umieszczony tylko przed *legacy* punktami końcowymi, opakowanie wielu operacji w jedno żądanie zbiorcze może całkowicie ominąć ochronę. ```json [ {"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}}, {"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}} ] ``` ### Timing the sliding-window Klasyczny limiter token-bucket lub leaky-bucket *resetuje się* na stałej granicy czasowej (na przykład co minutę). Jeśli okno jest znane (np. za pomocą komunikatów o błędach takich jak `X-RateLimit-Reset: 27`), wyślij maksymalną dozwoloną liczbę żądań **tuż przed** zresetowaniem wiadra, a następnie natychmiast wyślij kolejny pełny zryw. ``` |<-- 60 s window ‑->|<-- 60 s window ‑->| ###### ###### ``` Ta prosta optymalizacja może więcej niż podwoić Twoją przepustowość bez dotykania jakiejkolwiek innej techniki obejścia. --- ## Narzędzia - [**https://github.com/Hashtag-AMIN/hashtag-fuzz**](https://github.com/Hashtag-AMIN/hashtag-fuzz): Narzędzie do fuzzingu, które wspiera randomizację nagłówków, podzielone listy słów i rotację proxy w trybie round-robin. - [**https://github.com/ustayready/fireprox**](https://github.com/ustayready/fireprox): Automatycznie tworzy jednorazowe punkty końcowe AWS API Gateway, dzięki czemu każde żądanie pochodzi z innego adresu IP – idealne do pokonywania ograniczeń opartych na IP. - **Burp Suite – IPRotate + rozszerzenie**: Używa puli proxy SOCKS/HTTP (lub AWS API Gateway) do rotacji źródłowego IP w sposób przezroczysty podczas ataków *Intruder* i *Turbo Intruder*. - **Turbo Intruder (BApp)**: Silnik atakujący o wysokiej wydajności wspierający multiplexing HTTP/2; dostosuj `requestsPerConnection` do 100-1000, aby zredukować setki żądań do jednego połączenia. ## Odniesienia - PortSwigger Research – “Bypassing rate limits with GraphQL aliasing” (2023) - PortSwigger Research – “HTTP/2: The Sequel is Always Worse” (sekcja *Connection-based throttling*) (2024) {{#include ../banners/hacktricks-training.md}}