
Un outil CLI léger pour détecter et exploiter systématiquement les conditions de course dans les applications web, les API et les services modernes.
Les conditions de concurrence représentent l'une des vulnérabilités de sécurité les plus impactantes dans les applications modernes, mais elles restent mal couvertes par les scanners automatisés. Alors que des outils comme Nuclei, ffuf et sqlmap excellent dans la détection des vulnérabilités statiques, ils sont fondamentalement aveugles aux problèmes liés à la concurrence.
Les testeurs d'intrusion sont aujourd'hui confrontés à un choix : écrire manuellement des scripts jetables pour chaque mission, ou ignorer complètement les tests de conditions de concurrence. Aucune des deux options n'est scalable ou professionnelle.
RatRace résout ce problème en fournissant un flux de travail soigné et reproductible pour les tests de conditions de concurrence — transformant ce qui était autrefois du script ad-hoc en un processus systématique qui s'intègre aux pipelines CI/CD et génère des rapports professionnels.
Les vulnérabilités de conditions de concurrence apparaissent fréquemment dans des zones à fort impact :
Ces bugs rapportent systématiquement les plus hautes primes dans les programmes de bug bounty car ils menacent directement le chiffre d'affaires et la confiance des clients.
Définissez une fois les scénarios de concurrence en YAML, réutilisez-les entre projets. Le format reprend celui des modèles Nuclei pour une familiarité immédiate :
id: checkout-race
info:
name: Checkout Duplicate Order Race
severity: critical
race:
mode: burst
concurrency: 20
request:
method: POST
path: /api/v1/checkout
headers:
Authorization: "Bearer {{session}}"
body: '{"item_id": "SKU-001"}'
validate:
follow_up:
method: GET
path: /api/v1/orders?user={{user_id}}
expect:
json_field: "orders.length"
condition: equals
value: 1
Mode Rafale (Burst) — Requêtes parallèles basées sur goroutines avec synchronisation précise (stable, prêt pour la production)
Synchronisation du dernier octet (Last-Byte Sync) — Attaque au niveau TCP HTTP/1.1 (implémentation prête, phase de test)
Paquet unique (Single-Packet) — Attaque basée sur les trames HTTP/2 (implémentation prête, phase de test)
RatRace automatiquement :
equals, not_equals, greater_than, containsImporter des requêtes existantes :
# Depuis des commandes curl
ratrace import --curl 'curl -X POST https://api.example.com/checkout ...' -o template.yaml
# Depuis des fichiers HAR exportés de Burp
ratrace import --har session.har -o template.yaml
Automatisation CI/CD :
ratrace race -u $TARGET -t template.yaml --silent
echo $? # Code de sortie 10 = concurrence détectée, 0 = propre
Génération de rapports professionnels :
# JSON pour l'automatisation
ratrace race -u $TARGET -t template.yaml -o results/
# Rapports HTML (prévus en V2)
ratrace report --input results.json --format html
git clone https://github.com/bogdanticu88/ratrace.git
cd ratrace
go build ./cmd/ratrace
./ratrace --help
Prérequis : Go 1.24+
docker build -t ratrace:latest .
docker run --rm -it ratrace:latest race -u https://api.example.com -t template.yaml
# 1. Importer depuis curl ou utiliser un modèle existant
ratrace import --curl 'curl -X POST https://api.example.com/checkout ...' -o checkout.yaml
# 2. Exécuter la concurrence
ratrace race -u https://api.example.com -t checkout.yaml -m burst -c 20
# 3. Examiner les résultats
# La sortie affiche :
# 🔴 [CRITICAL] Checkout Duplicate Order Race
# Anomaly Rate: 91.7%
# Confidence: 84%
ratrace race \
-u https://shop.example.com \
-t examples/templates/checkout-race.yaml \
-m burst \
-c 25 \
--output results/
# S'exécute sans logs verbeux, se termine avec un code sémantique
ratrace race -u https://api.example.com -t template.yaml --silent
# Vérifier le code de sortie
if [ $? -eq 10 ]; then
echo "Condition de concurrence détectée !"
exit 1
fi
ratrace race -u <url> -t <template> [options]
Options :
-m, --mode string burst|lastbyte|singlepacket (par défaut depuis le modèle)
-c, --concurrency int Nombre de goroutines (par défaut 20)
-H, --header strings En-têtes personnalisés (répétables)
-x, --proxy string URL du proxy pour les requêtes
-o, --output string Répertoire de sortie pour les résultats
--timeout duration Délai d'attente de la requête (par défaut 10s)
--insecure Ignorer la vérification du certificat TLS
--dry-run Analyser le modèle et quitter
--silent Supprimer les logs, afficher uniquement les résultats
ratrace import [--curl <command> | --har <file>] -o <output.yaml>
Convertit les requêtes existantes (commandes curl ou exports HAR) en modèles RatRace.
Utile pour s'intégrer aux flux de travail existants.
ratrace report --input results.json --format [html|json] --output report.html
Génère des rapports lisibles par l'humain à partir des résultats des tests de concurrence.
ratrace ratelimit -u <url> -c <concurrency>
Teste si les points de terminaison sont vulnérables au contournement concurrent de la limitation de débit.
Les modèles sont des fichiers YAML qui définissent un scénario de concurrence. Référence complète :
id: unique-identifier
info:
name: "Nom lisible par l'humain"
severity: critical|high|medium|low|info
tags: [tag1, tag2]
race:
mode: burst|lastbyte|singlepacket
concurrency: 20
request:
method: POST|GET|PUT|DELETE|PATCH
path: /api/endpoint
headers:
Authorization: "Bearer {{token}}"
Custom-Header: "value"
body: '{"json": "body", "user": "{{user_id}}"}'
validate:
follow_up:
method: GET
path: /api/orders?user={{user_id}}
expect:
json_field: "orders.length"
condition: equals|greater_than|contains|not_equals
value: 1
Variables (utilisez les placeholders {{name}}) :
ratrace race ... -H "Authorization: Bearer {{session_token}}"Une journalisation propre et codée par couleur affiche la progression du test :
[INF] Loading template path=checkout-race.yaml
[INF] Template loaded id=checkout-race mode=burst
[RUN] Firing burst attack concurrency=20
[INF] All requests completed total=20
[RUN] Clustering responses baseline=17 anomalous=3
[RACE] Race condition detected anomaly_rate=15% confidence=94%
[CONF] Validation passed field=orders.length expected=1
[INF] Race test complete findings=1
Templates: 1 Requests: 20 Time: 3.2s
🔴 [CRITICAL] Checkout Duplicate Order Race
Anomaly Rate: 15.0%
Confidence: 94%
Status Diff: 201 → 200
Field Diffs: order_id (100 → 101)
Les résultats complets sont enregistrés dans results_<timestamp>.json pour l'automatisation et l'archivage :
{
"TemplateID": "checkout-race",
"Target": "https://api.example.com/api/v1/checkout",
"Mode": "burst",
"Concurrency": 20,
"TotalRequests": 20,
"Duration": 3200000000,
"Findings": [
{
"TemplateName": "Checkout Duplicate Order Race",
"Severity": "critical",
"AnomalyRate": 0.15,
"Confidence": 0.94,
"Diff": {
"StatusChanged": true,
"BaselineStatus": 201,
"AnomalousStatus": 200
}
}
]
}
Utilisés pour l'intégration CI/CD et l'automatisation :
| Code | Signification |
|---|---|
| 0 | Succès — aucune condition de concurrence trouvée |
| 3 | Erreur de données — modèle introuvable, erreur d'analyse |
| 4 | Erreur d'exécution — échec réseau, erreur du moteur |
| 10 | Condition de concurrence détectée — action requise |
| 11 | Contournement de la limitation de débit confirmé |
| 12 | Anomalie détectée mais validation non concluante |
make build # Compiler le binaire
make test # Tous les tests
make test-unit # Tests unitaires uniquement
make test-int # Tests d'intégration
make coverage # Rapport de couverture (HTML)
make lint # Exécuter le linter
make run-race # Compiler et exécuter l'exemple
cmd/ratrace/
└── main.go Point d'entrée, définition CLI
internal/
├── cmd/ Implémentations des sous-commandes
├── engine/ Modes d'attaque par concurrence (burst, lastbyte, singlepacket)
├── validator/ Regroupement des réponses, diff, vérifications de suivi
├── importer/ Analyseurs HAR et curl
├── reporter/ Sortie JSON et HTML
├── template/ Analyse YAML et templating
├── log/ Journalisation structurée en couleurs
└── models/ Types de données partagés
Les issues, PR et contributions de modèles sont les bienvenues. Merci de respecter :
make testmake lintMIT
RatRace est conçu pour les tests de sécurité autorisés, les programmes de bug bounty et les tests d'intrusion. Utilisez-le uniquement sur des systèmes que vous possédez ou pour lesquels vous avez une autorisation écrite explicite. Tester sans autorisation les systèmes d'autrui est illégal.
Bogdan Ticu — Recherche et ingénierie en sécurité
Pour les problèmes, questions ou rapports de sécurité : GitHub Issues