Race Condition

Une race condition est un bug de timing. Elle apparaît lorsqu'une application suppose que les opérations se déroulent les unes après les autres, mais qu'un attaquant les force à se produire en même temps. La forme classique est un écart time-of-check to time-of-use (TOCTOU) : l'application vérifie une condition (ce coupon a-t-il un solde ?) puis agit dessus (appliquer le crédit), et l'attaquant glisse des actions supplémentaires dans l'intervalle entre les deux.

Pourquoi c'est important

Les race conditions sont dangereuses précisément parce que chaque requête individuelle est légitime, ce qui leur permet d'échapper aux outils centrés sur les entrées, tout comme le font les vulnérabilités de logique métier. Elles sont aussi non déterministes : le même code peut se comporter correctement des milliers de fois et échouer de façon catastrophique lorsque le timing s'aligne, ce qui signifie que les tests séquentiels traditionnels ne les déclenchent presque jamais. Cette combinaison, impact élevé et faible détectabilité, en fait l'une des découvertes les plus gratifiantes en bug bounty et en test de sécurité des API.

Comment fonctionne une race condition

Imaginez un coupon valable une seule utilisation. Normalement, le déroulement est le suivant :

1. La requête arrive ; le serveur vérifie que le coupon est inutilisé.
2. Le serveur applique le crédit et le marque comme utilisé.

Maintenant, un attaquant envoie 50 requêtes d'utilisation exactement au même instant. Si les 50 atteignent l'étape 1 avant qu'aucune n'achève l'étape 2, le serveur les valide toutes par rapport au même état « inutilisé » et applique le crédit 50 fois.

Vérifier la condition

→fenêtre minuscule

L'attaquant modifie l'état

→

Utiliser un résultat périmé

La logique était correcte pour une requête à la fois, mais elle a cédé sous la concurrence. Cet intervalle, entre la vérification et l'utilisation, est l'endroit où vit l'attaque.

Où apparaissent les race conditions

Comment tester

Repérez les actions à usage unique ou limitées, puis envoyez de nombreuses requêtes identiques le plus simultanément possible. Burp Suite Repeater peut envoyer un groupe de requêtes en parallèle, et un court script Python utilisant des requêtes asynchrones peut faire de même.

Comment les prévenir

Se défendre contre les race conditions revient à supprimer l'hypothèse d'un ordre d'exécution sûr :

• Verrouillage : mutex, sémaphores ou verrous de ligne en base de données pour qu'une seule opération touche la ressource à la fois.
• Opérations atomiques : combinez la vérification et l'action en une seule étape indivisible.
• Clés d'idempotence : garantissent qu'une requête répétée ne prend effet qu'une seule fois.
• Contraintes de base de données : unicité, verrouillage optimiste (numéros de version) ou SELECT ... FOR UPDATE.

Les race conditions récompensent les chasseurs qui comprennent une application assez profondément pour savoir quelles actions sont censées ne se produire qu'une seule fois, puis qui prouvent que, sous pression, elles se produisent davantage.