mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
118 lines
8.3 KiB
Markdown
118 lines
8.3 KiB
Markdown
# Bypass de Limite de Taxa
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|
||
|
||
## Técnicas de Bypass de Limite de Taxa
|
||
|
||
### Explorando Endpoints Similares
|
||
|
||
Devem ser feitas tentativas de realizar ataques de força bruta em variações do endpoint alvo, como `/api/v3/sign-up`, incluindo alternativas como `/Sing-up`, `/SignUp`, `/singup`, `/api/v1/sign-up`, `/api/sign-up`, etc.
|
||
|
||
### Incorporando Caracteres em Branco em Código ou Parâmetros
|
||
|
||
Inserir bytes em branco como `%00`, `%0d%0a`, `%0d`, `%0a`, `%09`, `%0C`, `%20` em código ou parâmetros pode ser uma estratégia útil. Por exemplo, ajustar um parâmetro para `code=1234%0a` permite estender tentativas através de variações na entrada, como adicionar caracteres de nova linha a um endereço de e-mail para contornar limitações de tentativas.
|
||
|
||
### Manipulando a Origem do IP via Cabeçalhos
|
||
|
||
Modificar cabeçalhos para alterar a origem do IP percebida pode ajudar a evitar limitação de taxa baseada em IP. Cabeçalhos como `X-Originating-IP`, `X-Forwarded-For`, `X-Remote-IP`, `X-Remote-Addr`, `X-Client-IP`, `X-Host`, `X-Forwared-Host`, incluindo o uso de várias instâncias de `X-Forwarded-For`, podem ser ajustados para simular solicitações de diferentes IPs.
|
||
```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
|
||
```
|
||
### Mudando Outros Cabeçalhos
|
||
|
||
Alterar outros cabeçalhos de solicitação, como o user-agent e cookies, é recomendado, pois esses também podem ser usados para identificar e rastrear padrões de solicitação. Mudar esses cabeçalhos pode prevenir o reconhecimento e rastreamento das atividades do solicitante.
|
||
|
||
### Aproveitando o Comportamento do API Gateway
|
||
|
||
Alguns gateways de API são configurados para aplicar limitação de taxa com base na combinação de endpoint e parâmetros. Variando os valores dos parâmetros ou adicionando parâmetros não significativos à solicitação, é possível contornar a lógica de limitação de taxa do gateway, fazendo com que cada solicitação pareça única. Por exemplo `/resetpwd?someparam=1`.
|
||
|
||
### Fazendo Login na Sua Conta Antes de Cada Tentativa
|
||
|
||
Fazer login em uma conta antes de cada tentativa, ou a cada conjunto de tentativas, pode redefinir o contador de limitação de taxa. Isso é especialmente útil ao testar funcionalidades de login. Utilizando um ataque Pitchfork em ferramentas como Burp Suite, para rotacionar credenciais a cada poucas tentativas e garantindo que os redirecionamentos sejam marcados, pode efetivamente reiniciar os contadores de limitação de taxa.
|
||
|
||
### Utilizando Redes de Proxy
|
||
|
||
Implantar uma rede de proxies para distribuir as solicitações entre vários endereços IP pode efetivamente contornar limites de taxa baseados em IP. Roteando o tráfego através de vários proxies, cada solicitação parece originar de uma fonte diferente, diluindo a eficácia da limitação de taxa.
|
||
|
||
### Dividindo o Ataque Entre Diferentes Contas ou Sessões
|
||
|
||
Se o sistema alvo aplica limites de taxa com base em cada conta ou sessão, distribuir o ataque ou teste entre várias contas ou sessões pode ajudar a evitar a detecção. Essa abordagem requer gerenciar múltiplas identidades ou tokens de sessão, mas pode efetivamente distribuir a carga para permanecer dentro dos limites permitidos.
|
||
|
||
### Continue Tentando
|
||
|
||
Observe que, mesmo que um limite de taxa esteja em vigor, você deve tentar ver se a resposta é diferente quando o OTP válido é enviado. Em [**este post**](https://mokhansec.medium.com/the-2-200-ato-most-bug-hunters-overlooked-by-closing-intruder-too-soon-505f21d56732), o caçador de bugs descobriu que, mesmo que um limite de taxa seja acionado após 20 tentativas malsucedidas, respondendo com 401, se o válido for enviado, uma resposta 200 foi recebida.
|
||
|
||
---
|
||
|
||
### Abusando da multiplexação HTTP/2 e do pipeline de solicitações (2023-2025)
|
||
|
||
Implementações modernas de limitadores de taxa frequentemente contam **conexões TCP** (ou até mesmo solicitações HTTP/1.1 individuais) em vez do *número de streams HTTP/2* que uma conexão contém. Quando a mesma conexão TLS é reutilizada, um atacante pode abrir centenas de streams paralelos, cada um carregando uma solicitação separada, enquanto o gateway deduz apenas *uma* solicitação da cota.
|
||
```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
|
||
```
|
||
Se o limitador protege apenas `/verify`, mas não `/api/v2/verify`, você também pode combinar **confusão de caminho** com multiplexação HTTP/2 para *extremamente* alta velocidade de força bruta de OTP ou credenciais.
|
||
|
||
> 🐾 **Dica:** O [Turbo Intruder](https://portswigger.net/research/turbo-intruder) da PortSwigger suporta HTTP/2 e permite ajustar `maxConcurrentConnections` e `requestsPerConnection` para automatizar este ataque.
|
||
|
||
### Aliases GraphQL & operações em lote
|
||
|
||
GraphQL permite que o cliente envie **várias consultas ou mutações logicamente independentes em uma única solicitação** prefixando-as com *aliases*. Como o servidor executa cada alias, mas o limitador de taxa geralmente conta apenas *uma* solicitação, isso é uma forma confiável de contornar a limitação de login ou redefinição de senha.
|
||
```graphql
|
||
mutation bruteForceOTP {
|
||
a: verify(code:"111111") { token }
|
||
b: verify(code:"222222") { token }
|
||
c: verify(code:"333333") { token }
|
||
# … add up to dozens of aliases …
|
||
}
|
||
```
|
||
Olhe para a resposta: exatamente um alias retornará 200 OK quando o código correto for atingido, enquanto os outros estão com limite de taxa.
|
||
|
||
A técnica foi popularizada pela pesquisa da PortSwigger sobre “GraphQL batching & aliases” em 2023 e tem sido responsável por muitos pagamentos recentes de bug-bounty.
|
||
|
||
### Abuso de endpoints REST *batch* ou *bulk*
|
||
|
||
Algumas APIs expõem endpoints auxiliares, como `/v2/batch`, ou aceitam um **array de objetos** no corpo da solicitação. Se o limitador for colocado apenas na frente dos endpoints *legacy*, envolver várias operações dentro de uma única solicitação em massa pode contornar completamente a proteção.
|
||
```json
|
||
[
|
||
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"123"}},
|
||
{"path": "/login", "method": "POST", "body": {"user":"bob","pass":"456"}}
|
||
]
|
||
```
|
||
### Temporizando a janela deslizante
|
||
|
||
Um limitador clássico de token-bucket ou leaky-bucket *reinicia* em um limite de tempo fixo (por exemplo, a cada minuto). Se a janela for conhecida (por exemplo, através de mensagens de erro como `X-RateLimit-Reset: 27`), faça o número máximo permitido de solicitações **pouco antes** de o balde reiniciar, e então imediatamente faça outro estouro completo.
|
||
```
|
||
|<-- 60 s window ‑->|<-- 60 s window ‑->|
|
||
###### ######
|
||
```
|
||
Essa simples otimização pode mais do que dobrar sua taxa de transferência sem tocar em nenhuma outra técnica de bypass.
|
||
|
||
---
|
||
|
||
## Ferramentas
|
||
|
||
- [**https://github.com/Hashtag-AMIN/hashtag-fuzz**](https://github.com/Hashtag-AMIN/hashtag-fuzz): Ferramenta de fuzzing que suporta randomização de cabeçalhos, listas de palavras em chunks e rotação de proxy round-robin.
|
||
- [**https://github.com/ustayready/fireprox**](https://github.com/ustayready/fireprox): Cria automaticamente endpoints descartáveis do AWS API Gateway para que cada solicitação se origine de um endereço IP diferente – perfeito para derrotar a limitação baseada em IP.
|
||
- **Burp Suite – IPRotate + extensão**: Usa um pool de proxies SOCKS/HTTP (ou AWS API Gateway) para rotacionar o IP de origem de forma transparente durante ataques *Intruder* e *Turbo Intruder*.
|
||
- **Turbo Intruder (BApp)**: Motor de ataque de alto desempenho que suporta multiplexação HTTP/2; ajuste `requestsPerConnection` para 100-1000 para colapsar centenas de solicitações em uma única conexão.
|
||
|
||
## Referências
|
||
|
||
- 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” (seção *Connection-based throttling*) (2024) <https://portswigger.net/research/http2>
|
||
|
||
{{#include ../banners/hacktricks-training.md}}
|