Race Conditions

Qu'est-ce qu'une Race Condition ?#

Une race condition (CWE-362) survient quand le résultat de sécurité d'un système dépend du timing ou de l'entrelacement d'événements concurrents non coordonnés. En sécurité web, cela se manifeste systématiquement comme une séquence TOCTOU (Time-of-Check to Time-of-Use, CWE-367) : l'application lit une valeur pour prendre une décision de sécurité, puis agit sur cette décision dans une étape non atomique séparée. Un attaquant envoie plusieurs requêtes concurrentes pour exécuter l'étape "use" avant qu'un seul changement d'état n'ait été commis en base.

La classe de vulnérabilité a été redéfinie par James Kettle à Black Hat USA 2023 ("Smashing the State Machine"). Avant 2023, les race conditions web étaient considérées impraticables à exploiter de manière fiable à distance à cause du jitter réseau de 15-30ms. L'attaque single-packet — envoi de toutes les requêtes HTTP/2 dans un seul paquet TCP via synchronisation du dernier octet — a éliminé cette barrière. GMO Flatt Security a étendu cela à CODE BLUE 2024 avec le first sequence sync, atteignant jusqu'à 10 000 requêtes concurrentes en 166ms via fragmentation IP.

Les race conditions relèvent de OWASP A04:2021 (Insecure Design) car la cause racine est un défaut de conception de machine à états : l'application ne garantit jamais que la séquence vérification-et-action est atomique. Contrairement aux failles d'injection, les race conditions ne produisent aucune entrée malformée — l'attaque consiste entièrement en requêtes légitimes, bien formées, juste envoyées de manière concurrente.

Mécanisme#

Au cœur de toute race condition web se trouve une séquence vérification-et-action non atomique. La base de données détient l'état autoritatif, mais l'application le lit en mémoire, raisonne dessus, puis réécrit — créant une fenêtre où des lectures concurrentes voient toutes l'état pré-mise-à-jour.

L'attaque se déroule en quatre étapes :

1. L'attaquant identifie un endpoint transactionnel avec une garde (validité coupon, solde suffisant, rate limit, token à usage unique).
2. Via Turbo Intruder ou Burp Repeater "Send group in parallel", il envoie 20+ requêtes identiques via une connexion HTTP/2 dans un seul paquet TCP.
3. Le serveur traite plusieurs requêtes avant qu'une seule n'ait commis sa mise-à-jour d'état — toutes voient l'état pré-mise-à-jour.
4. L'attaquant vérifie en lisant l'état serveur post-burst : si le compteur s'est incrémenté de N au lieu de 1, la race est confirmée.

Un PoC fonctionnel avec httpx :

import asyncio
import httpx
 
async def race_coupon(url: str, headers: dict, body: dict, n: int = 20):
    """Race un endpoint de rédemption de coupon N fois en concurrence."""
    async with httpx.AsyncClient(http2=True, verify=False, timeout=30.0) as client:
        # Réchauffement de connexion — handshake TLS + HTTP/2 SETTINGS
        await client.get(url.rsplit("/", 1)[0] + "/", headers=headers)
        # N requêtes sur la même connexion HTTP/2
        tasks = [client.post(url, headers=headers, json=body) for _ in range(n)]
        responses = await asyncio.gather(*tasks, return_exceptions=True)
        success = [r for r in responses if not isinstance(r, Exception) and r.status_code == 200]
        return {"total": n, "success_count": len(success), "race_confirmee": len(success) > 1}

Variantes d'Attaque#

Le dépassement de limite (single-endpoint) est la race la plus courante en bug bounty. L'application vérifie un compteur (uses < max_uses, balance >= amount, already_voted == false), passe la vérification, puis incrémente/décrémente dans une opération séparée.

La JIT inconsistency est la catégorie la plus subtile. Kettle a documenté la fenêtre de construction partielle de Rails+Devise : une ligne utilisateur est insérée avec confirmation_token=NULL avant qu'un job asynchrone peuple le token, permettant une confirmation avec un token vide pendant cette fenêtre.

Exemples Réels#

CVE-2024-30088 — Noyau Windows (CISA KEV, juin 2024, CVSS 7.0) Un TOCTOU dans NtQueryInformationToken permettait une élévation de privilèges locale vers SYSTEM. Ajouté au catalogue CISA KEV en juin 2024 avec exploitation confirmée.

CVE-2025-22224 — VMware ESXi/Workstation (CISA KEV, mars 2025, CVSS 9.3) Un débordement de heap TOCTOU dans le sous-système VMCI permettait à un processus VM invité d'échapper vers l'hôte hyperviseur. Exploité dans des campagnes actives ciblant les infrastructures cloud avant le correctif de mars 2025.

CVE-2024-50379 + CVE-2024-56337 — Apache Tomcat (CVSS 9.8) TOCTOU de compilation JSP sur les systèmes de fichiers insensibles à la casse (Windows, macOS). Deux uploads concurrents au même chemin logique — FILE.JSP et file.txt — créent une race où la vérification d'extension voit .txt mais l'étape de compilation exécute le bytecode JSP. GET /file.jsp obtient RCE avec les privilèges du service Tomcat. Corrigé dans Tomcat 11.0.2 / 10.1.34 / 9.0.98.

CVE-2024-58248 — nopCommerce Gift Card Double-Spend (CVSS 7.5) Des requêtes de rédemption de carte cadeau concurrentes dans nopCommerce < 4.80.0 passaient la vérification de solde avant tout UPDATE. Une seule carte cadeau de 100€ pouvait être rachetée N fois en parallèle.

CVE-2024-45300 — alf.io Promo Code Race (CVSS 7.5) La plateforme de billetterie alf.io (≤ 2.0-M4-2402) permettait des applications concurrentes de code promo qui contournaient les limites d'utilisation.

HackerOne #55140 — OAuth 2 Race (Internet Bug Bounty, 2 500$) Des requêtes d'échange de code d'autorisation concurrentes produisaient deux paires distinctes access_token/refresh_token depuis un seul code. L'attaquant conservait une paire de tokens valide même après la révocation totale par la victime.

InnoGames Email Activation Race (2 000$) Des requêtes d'activation d'email concurrentes incrémentaient un compteur de monnaie virtuelle N fois au lieu d'une fois. Une seule activation en 20 requêtes concurrentes accordait 20× le bonus de bienvenue. 137 votes HackerOne.

Détection#

Test Manuel#

1. Identifier les endpoints transactionnels avec une garde : /redeem, /apply, /withdraw, /transfer, /confirm, /vote, /refresh, /oauth/token.
2. Établir un état de base : envoyer une requête unique et observer le changement d'état attendu.
3. Dans Burp Suite, créer un groupe de 20 requêtes identiques dans Repeater. Sélectionner Send group in parallel (single-packet attack).
4. Examiner les réponses : plusieurs 200 OK là où un seul est attendu = signal préliminaire.
5. Confirmer avec la preuve read-race-read : GET état avant, burst, GET état après. Si le compteur s'est incrémenté de N > 1, la race est confirmée.
6. Pour les backends cold (Lambda, Cloud Run), envoyer 1-3 requêtes de réchauffement avant le burst.

Détection Automatisée#

Turbo Intruder avec Engine.BURP2 reste le standard pour la confirmation PoC :

# Turbo Intruder — attaque par gate single-packet
def queueRequests(target, wordlists):
    engine = RequestEngine(
        endpoint=target.endpoint,
        concurrentConnections=1,
        engine=Engine.BURP2  # Single-packet HTTP/2
    )
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')  # Tir simultané des 20
 
def handleResponse(req, interesting):
    table.add(req)

Signaux clés :

• M ≥ 2 des N requêtes retournant 2xx sur un endpoint à usage unique (haute confiance)
• N resource IDs distincts dans N réponses de succès concurrentes (définitif — prouve la duplication)
• Compteur d'état post-race = N au lieu de 1 (signal le plus fort — élimine les FP de cache CDN)

BreachVex détecte les race conditions via plusieurs techniques complémentaires : correspondance structurelle de patterns d'URL transactionnels, bursts HTTP/2 concurrents avec analyse différentielle de réponse, et preuve read-race-read avant toute confirmation. Les endpoints financiers déclenchent toujours une validation dual-judge avant marquage Critical.

Prévention#

Opérations Atomiques en Base de Données#

La défense la plus fiable élimine la fenêtre check-et-use au niveau base de données :

-- VULNÉRABLE : SELECT séparé puis UPDATE — fenêtre de race entre les deux
SELECT used FROM coupons WHERE code = 'SAVE25';
-- ...logique applicative...
UPDATE coupons SET used = TRUE WHERE code = 'SAVE25';
 
-- CORRIGÉ : UPDATE conditionnel atomique
UPDATE coupons
SET used = TRUE, redeemed_by = $1, redeemed_at = NOW()
WHERE code = $2 AND used = FALSE
RETURNING id, amount;
-- 0 lignes retournées = déjà utilisé — aucun SELECT séparé nécessaire

Pour les opérations de solde, SELECT FOR UPDATE acquiert un verrou en écriture au niveau ligne :

BEGIN;
SELECT balance FROM accounts WHERE id = $1 FOR UPDATE;
-- Les transactions concurrentes BLOQUENT ici jusqu'au commit
UPDATE accounts SET balance = balance - $2 WHERE id = $1 AND balance >= $2;
COMMIT;

Idempotence Redis SETNX#

Pour les flux cross-service où les transactions DB ne peuvent pas couvrir les frontières de service :

import redis.asyncio as redis
import uuid
 
async def redeem_coupon_safe(code: str, user_id: int, r: redis.Redis):
    lock_key = f"coupon_lock:{code}"
    lock_id = str(uuid.uuid4())
 
    # Atomique : SET key seulement si absente (NX) avec expiry 10s
    acquired = await r.set(lock_key, lock_id, nx=True, ex=10)
    if not acquired:
        raise ValueError("Rédemption concurrente en cours — réessayez")
 
    try:
        coupon = await db.get_coupon(code)
        if coupon.used:
            raise ValueError("Coupon déjà utilisé")
        await db.mark_coupon_used(code, user_id)
    finally:
        # Lua : supprimer seulement si on possède le verrou
        await r.eval(
            "if redis.call('GET',KEYS[1])==ARGV[1] then return redis.call('DEL',KEYS[1]) else return 0 end",
            1, lock_key, lock_id
        )

Pour les endpoints API, appliquer un header Idempotency-Key :

@router.post("/transfer")
async def transfer(body: TransferRequest, idempotency_key: str = Header(...)):
    cached_key = f"idem:{idempotency_key}"
    if existing := await redis.get(cached_key):
        return existing
    result = await do_transfer(body)
    await redis.setex(cached_key, 86400, result.model_dump_json())
    return result

Niveau d'Isolation et Patterns ORM#

Augmenter le niveau d'isolation PostgreSQL à SERIALIZABLE pour les opérations financières. Éviter le pattern read-modify-write ORM :

# VULNÉRABLE — lit en mémoire, modifie, sauvegarde
account = db.query(Account).filter_by(id=account_id).first()
account.balance -= amount
db.commit()
 
# CORRIGÉ — expression atomique évaluée en DB
from sqlalchemy import update
db.execute(
    update(Account)
    .where(Account.id == account_id, Account.balance >= amount)
    .values(balance=Account.balance - amount)
)
db.commit()

Ressources#

• PortSwigger Research — Smashing the State Machine (Kettle, BH2023)
• Flatt Security — Beyond the Limit : First Sequence Sync (CODE BLUE 2024)
• PortSwigger Web Security Academy — Race Conditions
• CWE-362 : Concurrent Execution Using Shared Resource