Rate Limit Bypass

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Rate limit bypass techniques

Exploring Similar Endpoints

Il faut tenter d’effectuer des brute force attacks sur des variantes de l’endpoint ciblé, comme /api/v3/sign-up, en incluant des alternatives telles que /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up, etc.

Incorporating Blank Characters in Code or Parameters

L’insertion d’octets ou de caractères blancs tels que %00, %0d%0a, %0d, %0a, %09, %0C, %20 dans le code ou les paramètres peut être une stratégie utile. Par exemple, modifier un paramètre en code=1234%0a permet d’étendre les tentatives via des variations d’entrée, comme en ajoutant des retours à la ligne dans une adresse e-mail pour contourner les limitations de tentatives.

Manipulating IP Origin via Headers

La modification des headers pour altérer l’origine IP perçue peut aider à échapper au rate limiting basé sur l’IP. Des headers tels que X-Originating-IP, X-Forwarded-For, X-Remote-IP, X-Remote-Addr, X-Client-IP, X-Host, X-Forwared-Host, y compris l’utilisation de plusieurs occurrences de X-Forwarded-For, peuvent être ajustés pour simuler des requêtes depuis différentes IP.

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

Modifier d’autres en-têtes

Il est recommandé de modifier d’autres en-têtes de requête tels que user-agent et cookies, car ils peuvent aussi être utilisés pour identifier et suivre les motifs de requêtes. Changer ces en-têtes peut empêcher la reconnaissance et le suivi des activités du requester.

Tirer parti du comportement des API gateways

Certaines API gateways sont configurées pour appliquer le rate limiting en fonction de la combinaison d’endpoint et de paramètres. En variant les valeurs des paramètres ou en ajoutant des paramètres non significatifs à la requête, il est possible de contourner la logique de rate-limiting de la gateway, faisant apparaître chaque requête comme unique. Par exemple /resetpwd?someparam=1.

Se connecter à votre compte avant chaque tentative

Se connecter à un compte avant chaque tentative, ou avant chaque série de tentatives, peut réinitialiser le compteur de rate limit. Cela est particulièrement utile lors du test des fonctionnalités de login. Utiliser une Pitchfork attack dans des outils comme Burp Suite pour faire tourner les credentials toutes les quelques tentatives et en veillant à ce que follow redirects soit coché peut effectivement redémarrer les compteurs de rate limit.

Utiliser des réseaux de proxies

Déployer un réseau de proxies pour répartir les requêtes sur plusieurs adresses IP peut contourner efficacement les IP-based rate limits. En routant le trafic via différents proxies, chaque requête semble provenir d’une source différente, diminuant l’efficacité de la rate limit.

Répartir l’attaque sur différents comptes ou sessions

Si le système cible applique des rate limits par compte ou par session, répartir l’attaque ou le test sur plusieurs comptes ou sessions peut aider à éviter la détection. Cette approche nécessite de gérer plusieurs identités ou session tokens, mais peut efficacement répartir la charge pour rester dans les limites autorisées.

Continuer d’essayer

Notez que même si un rate limit est en place, vous devriez vérifier si la réponse est différente lorsque l’OTP valide est envoyé. In this post, le bug hunter a découvert que même si un rate limit est déclenché après 20 tentatives infructueuses en répondant avec 401, si la valeur valide était envoyée une réponse 200 a été reçue.

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

Les implémentations modernes de rate–limiter comptent fréquemment les TCP connections (ou même des requêtes individuelles HTTP/1.1) au lieu du number of HTTP/2 streams qu’une connexion contient. Lorsque la même connexion TLS est réutilisée, un attaquant peut ouvrir des centaines de streams parallèles, chacun transportant une requête distincte, tandis que la gateway ne déduit qu’une requête du quota.

# 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

Si le limiteur protège uniquement /verify mais pas /api/v2/verify, vous pouvez aussi combiner path confusion avec HTTP/2 multiplexing pour un brute-forcing d’OTP ou de credentials extrêmement rapide.

🐾 Astuce : PortSwigger’s Turbo Intruder prend en charge HTTP/2 et vous permet d’ajuster finement maxConcurrentConnections et requestsPerConnection pour automatiser cette attaque.

GraphQL aliases & batched operations

GraphQL permet au client d’envoyer plusieurs queries ou mutations logiquement indépendantes dans une seule requête en les préfixant avec des aliases. Parce que le serveur exécute chaque alias mais que le rate-limiter compte souvent seulement une requête, c’est un contournement fiable du throttling pour 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 …
}

Regardez la réponse : exactement un alias renverra 200 OK lorsque le bon code est atteint, tandis que les autres sont rate-limited.

La technique a été popularisée par la recherche de PortSwigger sur “GraphQL batching & aliases” en 2023 et a entraîné de nombreux paiements bug-bounty récents.

Abus des endpoints REST batch ou bulk

Certaines API exposent des helper endpoints tels que /v2/batch ou acceptent un tableau d’objets dans le corps de la requête. Si le limiter est placé uniquement devant les legacy endpoints, encapsuler plusieurs opérations dans une seule requête bulk peut complètement contourner la protection.

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

Synchronisation de la sliding-window

Un limiteur token-bucket ou leaky-bucket classique se réinitialise à des intervalles temporels fixes (par exemple, toutes les minutes). Si la fenêtre est connue (p. ex. via des messages d’erreur tels que X-RateLimit-Reset: 27), envoyez le nombre maximal de requêtes autorisées juste avant que le bucket ne se réinitialise, puis déclenchez immédiatement une autre rafale complète.

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

Cette simple optimisation peut plus que doubler votre débit sans toucher à aucune autre technique de bypass.

Passage à WebSockets / gRPC streaming après le handshake

Beaucoup de edge rate-limiters n’inspectent que la requête HTTP initiale. Une fois la connexion passée à WebSocket (HTTP 101) ou à gRPC bidirectional streaming, les messages suivants contournent souvent les compteurs de requêtes par seconde parce qu’ils ne sont plus des requêtes HTTP distinctes. La documentation de Cloudflare note que seule la requête d’upgrade initiale est soumise aux règles WAF/rate-limiting ; les frames envoyées ensuite sont opaques.

Flux de travail pratique:

# 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

Si le endpoint login/OTP expose à la fois des variantes HTTP et WebSocket/gRPC, établissez d’abord le canal upgradé, puis envoyez plusieurs codes via cette même connexion pour contourner les per-request throttles.

Exploiter les compteurs shardés par PoP des CDN

Certaines CDNs shardent les rate-limit counters par data center/PoP plutôt qu’à l’échelle globale. Cloudflare indique explicitement que les compteurs ne sont pas partagés entre les data centers. En routant les requêtes via des egress nodes dans de nombreuses régions (residential proxy pools, anycast VPNs, or cloud VMs pinned to different continents), vous multipliez le débit autorisé : chaque PoP maintient un bucket indépendant pour la même clé.

Disposition rapide et basique utilisant des open proxies (exemple avec proxychains + une liste tournante par pays) :

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

Assurez-vous que le limiter key n’est pas par compte ; sinon, faites aussi tourner les user IDs / session tokens.

Outils

  • https://github.com/Hashtag-AMIN/hashtag-fuzz: Outil de fuzzing qui prend en charge header randomisation, chunked word-lists et round-robin proxy rotation.
  • https://github.com/ustayready/fireprox: Crée automatiquement des endpoints AWS API Gateway jetables afin que chaque requête provienne d’une adresse IP différente — parfait pour déjouer l’IP-based throttling.
  • Burp Suite – IPRotate + extension: Utilise un pool de SOCKS/HTTP proxies (ou AWS API Gateway) pour faire tourner l’adresse IP source de façon transparente lors des attaques Intruder et Turbo Intruder.
  • Turbo Intruder (BApp): Moteur d’attaque haute performance supportant HTTP/2 multiplexing ; ajustez requestsPerConnection à 100-1000 pour regrouper des centaines de requêtes dans une seule connexion.

Références

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks