| .. | ||
| probe.sh | ||
| README.md | ||
rate-limit-probe
Mesure si l'endpoint d'authentification (ou tout endpoint sensible) de la preprod met en place un rate-limiting / verrouillage contre le bruteforce.
Principe
Envoie RATE_PROBE_COUNT requêtes (20 par défaut) avec un mauvais
mot de passe sur LOGIN_PATH et observe les codes de réponse :
- 429 → rate-limiting actif (bon). Le seuil (après combien de requêtes) se lit dans le journal.
- changement soudain de code (ex : 401 → 403/423) → verrouillage (lockout) après N échecs.
- rien de tout ça (toujours 401/400) → AUCUN rate-limit : vulnérabilité, le bruteforce n'est pas freiné.
Lancement
./probe.sh
Paramètres (dans targets.env) :
RATE_PROBE_COUNT— nombre de requêtes (défaut 20).RATE_PROBE_DELAY— délai entre requêtes en secondes (0 = rafale ; pour tester le rate-limit on veut justement une rafale, mais gardez un count modéré).
Sortie
- stdout : verdict (rate-limit actif / lockout / absent).
output/rate-limit.log:horodatage \t n/N \t code.
Actions typiques
- Aucun rate-limit → en ajouter un au reverse proxy (ex :
limit_reqnginx) ou côté application (bucket par IP+utilisateur). - Rate-limit trop agressif (429 dès la 2e requête) → risque de bloquer les légitimes ; ajuster le seuil.