mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
118 lines
8.1 KiB
Markdown
118 lines
8.1 KiB
Markdown
# 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) <https://portswigger.net/research/graphql-authorization-bypass>
|
||
- PortSwigger Research – “HTTP/2: The Sequel is Always Worse” (sekcja *Connection-based throttling*) (2024) <https://portswigger.net/research/http2>
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|