# 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) - PortSwigger Research – “HTTP/2: The Sequel is Always Worse” (seção *Connection-based throttling*) (2024) {{#include ../banners/hacktricks-training.md}}