Rate Limit Bypass

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Rate limit bypass techniques

Exploring Similar Endpoints

Deve-se tentar realizar brute force attacks 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.

Incorporating Blank Characters in Code or Parameters

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 as tentativas através de variações na entrada, como adicionar caracteres de nova linha a um endereço de email para contornar limitações de tentativas.

Manipulating IP Origin via Headers

Modificar cabeçalhos para alterar a origem IP percebida pode ajudar a evadir rate limiting 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 usar múltiplas instâncias de X-Forwarded-For, podem ser ajustados para simular requisições de IPs diferentes.

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

Alterando Outros Cabeçalhos

Recomenda-se alterar outros headers de requisição, como user-agent e cookies, pois eles também podem ser usados para identificar e rastrear padrões de requisições. Alterar esses headers pode impedir o reconhecimento e o rastreamento das atividades do solicitante.

Aproveitando o Comportamento do API Gateway

Alguns API gateways são configurados para aplicar limite de taxa com base na combinação de endpoint e parâmetros. Variando os valores dos parâmetros ou adicionando parâmetros sem significado à requisição, é possível contornar a lógica de limite de taxa do gateway, fazendo com que cada requisição pareça única. Por exemplo /resetpwd?someparam=1.

Entrar na Sua Conta Antes de Cada Tentativa

Entrar numa conta antes de cada tentativa, ou a cada conjunto de tentativas, pode reiniciar o contador de limite de taxa. Isso é especialmente útil ao testar funcionalidades de login. Utilizar um Pitchfork attack em ferramentas como Burp Suite, para rotacionar credenciais a cada poucas tentativas e garantindo que follow redirects esteja marcado, pode efetivamente reiniciar os contadores de limite de taxa.

Utilizando Redes de Proxy

Implantar uma rede de proxies para distribuir as requisições por vários endereços IP pode contornar efetivamente limites de taxa baseados em IP. Ao rotear o tráfego através de vários proxies, cada requisição parece se originar de uma fonte diferente, diluindo a eficácia do limite de taxa.

Dividindo o Ataque entre Diferentes Contas ou Sessões

Se o sistema alvo aplica limites de taxa por conta ou por sessão, distribuir o ataque ou teste entre várias contas ou sessões pode ajudar a evitar detecção. Essa abordagem exige 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 se um limite de taxa estiver em vigor, você deve tentar ver se a resposta é diferente quando o OTP válido é enviado. Em este post, o bug hunter descobriu que, mesmo quando um limite de taxa é acionado após 20 tentativas sem sucesso (retornando 401), o envio do OTP válido ainda resultou em uma resposta 200.

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

Implementações modernas de rate–limiter frequentemente contam TCP connections (ou até mesmo requisições HTTP/1.1 individuais) em vez do number of HTTP/2 streams 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 requisição separada, enquanto o gateway somente desconta one request da cota.

# 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 path confusion com HTTP/2 multiplexing para brute-forcing de OTP ou credenciais em velocidade extremamente alta.

🐾 Dica: PortSwigger’s Turbo Intruder supports HTTP/2 and lets you fine-tune maxConcurrentConnections and requestsPerConnection to automate this attack.

GraphQL aliases & batched operations

GraphQL permite que o cliente envie várias queries ou mutations logicamente independentes em uma única requisição prefixando-as com aliases. Como o servidor executa cada alias, mas o rate-limiter frequentemente conta apenas uma requisição, isso é um bypass confiável para throttling de login ou 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 …
}

Veja a resposta: exatamente um alias retornará 200 OK quando o código correto for atingido, enquanto os outros são rate-limited.

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 batch ou bulk endpoints REST

Algumas APIs expõem endpoints auxiliares como /v2/batch ou aceitam um array of objects no corpo da requisição. Se o limiter estiver colocado apenas na frente dos endpoints legacy, agrupar múltiplas operações dentro de uma única bulk request pode contornar completamente a proteção.

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

Sincronizando o sliding-window

Um limitador clássico token-bucket ou leaky-bucket reinicia em uma fronteira de tempo fixa (por exemplo, a cada minuto). Se a window for conhecida (por exemplo, via mensagens de erro como X-RateLimit-Reset: 27), dispare o número máximo permitido de requests logo antes do bucket reiniciar, e em seguida dispare outro burst completo.

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

Esta otimização simples pode mais do que dobrar seu throughput sem mexer em qualquer outra técnica de bypass.

Atualizar para WebSockets / gRPC streaming após o handshake

Muitos edge rate-limiters inspecionam apenas a requisição HTTP inicial. Depois que a conexão é atualizada para WebSocket (HTTP 101) ou gRPC bidirectional streaming, mensagens subsequentes frequentemente contornam contadores de requisições por segundo porque não são mais requisições HTTP separadas. Os próprios docs da Cloudflare observam que somente a requisição inicial de upgrade está sujeita às regras do WAF/rate-limiting; frames enviados depois são opacos.

Fluxo prático:

# 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

Se o login/OTP endpoint expõe variantes HTTP e WebSocket/gRPC, estabeleça primeiro o canal atualizado e então spray codes dentro dessa única conexão para evitar per-request throttles.

Explorando contadores shardados por PoP de CDN

Algumas CDNs shardam contadores de rate-limit por data center/PoP em vez de globalmente. Cloudflare declara explicitamente que os contadores não são compartilhados entre data centers. Ao rotear requests através de egress nodes em várias regiões (residential proxy pools, anycast VPNs, ou cloud VMs fixadas em continentes diferentes), você multiplica o throughput permitido: cada PoP mantém um bucket independente para a mesma key.

Quick and dirty layout using open proxies (exemplo com proxychains + a country‑rotating list):

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

Certifique-se de que a chave do limitador não seja por conta; caso contrário, rotacione também os IDs de usuário / tokens de sessão.

Ferramentas

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Ferramenta de fuzzing que suporta randomização de headers, word-lists em chunks e rotação round-robin de proxies.
  • https://github.com/ustayready/fireprox: Cria automaticamente endpoints descartáveis no AWS API Gateway para que cada requisição se origine de um IP diferente — perfeito para contornar limitação baseada em IP.
  • Burp Suite – IPRotate + extension: 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 com suporte a multiplexação HTTP/2; ajuste requestsPerConnection para 100-1000 para agrupar centenas de requisições em uma única conexão.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks