Contournement de la Limite de Taux

Reading time: 8 minutes

Techniques de contournement de la limite de taux

Exploration des Points de Terminaison Similaires

Des tentatives devraient être faites pour effectuer des attaques par force brute sur des variations du point de terminaison ciblé, comme /api/v3/sign-up, y compris des alternatives comme /Sing-up, /SignUp, /singup, /api/v1/sign-up, /api/sign-up, etc.

Incorporation de Caractères Vides dans le Code ou les Paramètres

L'insertion de bytes vides comme %00, %0d%0a, %0d, %0a, %09, %0C, %20 dans le code ou les paramètres peut être une stratégie utile. Par exemple, ajuster un paramètre à code=1234%0a permet d'étendre les tentatives à travers des variations d'entrée, comme l'ajout de caractères de nouvelle ligne à une adresse e-mail pour contourner les limitations de tentatives.

Manipulation de l'Origine IP via les En-têtes

Modifier les en-têtes pour altérer l'origine IP perçue peut aider à échapper à la limitation de taux basée sur l'IP. Des en-têtes 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 instances de X-Forwarded-For, peuvent être ajustés pour simuler des requêtes provenant de 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

Changer d'autres en-têtes

Il est recommandé de modifier d'autres en-têtes de requête tels que l'agent utilisateur et les cookies, car ceux-ci peuvent également être utilisés pour identifier et suivre les modèles de requêtes. Changer ces en-têtes peut empêcher la reconnaissance et le suivi des activités du demandeur.

Tirer parti du comportement de la passerelle API

Certaines passerelles API sont configurées pour appliquer des limites de taux en fonction de la combinaison de l'endpoint et des 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 limitation de taux de la passerelle, rendant chaque requête unique. Par exemple /resetpwd?someparam=1.

Se connecter à votre compte avant chaque tentative

Se connecter à un compte avant chaque tentative, ou chaque ensemble de tentatives, peut réinitialiser le compteur de limite de taux. Cela est particulièrement utile lors des tests de fonctionnalités de connexion. Utiliser une attaque Pitchfork dans des outils comme Burp Suite, pour faire tourner les identifiants toutes les quelques tentatives et s'assurer que les redirections sont marquées, peut efficacement redémarrer les compteurs de limite de taux.

Utiliser des réseaux de proxy

Déployer un réseau de proxies pour distribuer les requêtes sur plusieurs adresses IP peut contourner efficacement les limites de taux basées sur l'IP. En acheminant le trafic à travers divers proxies, chaque requête semble provenir d'une source différente, diluant ainsi l'efficacité de la limite de taux.

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

Si le système cible applique des limites de taux sur une base 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 jetons de session, mais peut efficacement répartir la charge pour rester dans les limites autorisées.

Continuez à essayer

Notez que même si une limite de taux est en place, vous devriez essayer de voir si la réponse est différente lorsque le OTP valide est envoyé. Dans ce post, le chasseur de bugs a découvert que même si une limite de taux est déclenchée après 20 tentatives infructueuses en répondant avec 401, si le valide était envoyé, une réponse 200 était reçue.

Abuser du multiplexage HTTP/2 et du pipelining des requêtes (2023-2025)

Les implémentations modernes de limiteurs de taux comptent fréquemment les connexions TCP (ou même les requêtes HTTP/1.1 individuelles) au lieu du nombre de flux HTTP/2 qu'une connexion contient. Lorsque la même connexion TLS est réutilisée, un attaquant peut ouvrir des centaines de flux parallèles, chacun transportant une requête distincte, tandis que la passerelle 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 également combiner la confusion de chemin avec le multiplexage HTTP/2 pour un extrêmement rapide OTP ou brute-forcing de crédentiels.

🐾 Astuce : Le Turbo Intruder de PortSwigger prend en charge HTTP/2 et vous permet d'affiner maxConcurrentConnections et requestsPerConnection pour automatiser cette attaque.

Aliases GraphQL & opérations groupées

GraphQL permet au client d'envoyer plusieurs requêtes ou mutations logiquement indépendantes dans une seule requête en les préfixant avec des alias. Comme le serveur exécute chaque alias mais que le limiteur de débit compte souvent seulement une requête, c'est un contournement fiable pour le throttling de connexion ou de réinitialisation de mot de passe.

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 code correct est atteint, tandis que les autres sont soumis à une limitation de taux.

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

Abus des points de terminaison REST batch ou bulk

Certaines API exposent des points de terminaison d'assistance tels que /v2/batch ou acceptent un tableau d'objets dans le corps de la requête. Si le limiteur est placé uniquement devant les points de terminaison legacy, envelopper 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"}}
]

Chronométrage de la fenêtre glissante

Un limiteur classique de type token-bucket ou leaky-bucket se réinitialise à une frontière temporelle fixe (par exemple, chaque minute). Si la fenêtre est connue (par exemple, via des messages d'erreur tels que X-RateLimit-Reset: 27), effectuez le nombre maximum de requêtes autorisées juste avant que le seau ne se réinitialise, puis effectuez immédiatement une autre pleine rafale.

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

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

Outils

• https://github.com/Hashtag-AMIN/hashtag-fuzz : Outil de fuzzing qui prend en charge la randomisation des en-têtes, des listes de mots en morceaux et la rotation de proxy en round-robin.
• https://github.com/ustayready/fireprox : Crée automatiquement des points de terminaison AWS API Gateway jetables afin que chaque requête provienne d'une adresse IP différente – parfait pour vaincre le throttling basé sur l'IP.
• Burp Suite – IPRotate + extension : Utilise un pool de proxies SOCKS/HTTP (ou AWS API Gateway) pour faire tourner l'IP source de manière transparente lors des attaques Intruder et Turbo Intruder.
• Turbo Intruder (BApp) : Moteur d'attaque haute performance prenant en charge le multiplexage HTTP/2 ; réglez requestsPerConnection à 100-1000 pour regrouper des centaines de requêtes en une seule connexion.

Références

• 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” (section Connection-based throttling) (2024) https://portswigger.net/research/http2