Race Condition (TOCTOU)

Une race condition est une vulnérabilité où le comportement du système dépend de l'ordre d'exécution de plusieurs threads ou processus concurrents. Dans un contexte sécurité, le pattern le plus classique est le TOCTOU (Time-of-Check to Time-of-Use) : entre le moment où une condition est vérifiée et le moment où l'action est exécutée, un attaquant peut modifier l'état pour bypasser le contrôle.

Exemples : (1) un système bancaire vérifie le solde avant un virement — un attaquant lance 1000 virements en parallèle et chacun voit le solde initial, dépassant le solde réel (cas réel : exploits Starbucks gift card en 2015) ; (2) un script vérifie qu'un fichier existe puis l'ouvre — un attaquant remplace le fichier par un symlink entre les deux opérations (privilege escalation classique sous Unix) ; (3) un système de coupons one-time use peut être utilisé N fois si la déduplication n'est pas atomique.

Mitigations : (1) opérations atomiques (CAS — compare-and-swap, transactions SQL avec SELECT FOR UPDATE) ; (2) verrouillage explicite (mutex, semaphores) ; (3) idempotence (idempotency keys côté API) ; (4) éviter le pattern check-then-act, utiliser try-and-recover. Les race conditions sont difficiles à détecter en testing classique mais ThreadSanitizer, Helgrind et le fuzzing permettent de les exposer.