Race Condition

Una race condition è un bug di tempistica. Si manifesta quando un'applicazione presuppone che le operazioni avvengano una dopo l'altra, ma un attaccante le forza ad avvenire nello stesso momento. La forma classica è un divario time-of-check to time-of-use (TOCTOU): l'applicazione verifica una condizione (questo coupon ha credito?) e poi agisce di conseguenza (applica il credito), mentre l'attaccante infila azioni aggiuntive nella finestra tra i due passaggi.

Perché è Importante

Le race condition sono pericolose proprio perché ogni singola richiesta è legittima, quindi sfuggono agli strumenti focalizzati sull'input esattamente come fanno le vulnerabilità della logica di business. Sono anche non deterministiche: lo stesso codice può comportarsi correttamente migliaia di volte e fallire in modo catastrofico quando la tempistica si allinea, il che significa che il testing sequenziale tradizionale quasi non le innesca mai. Questa combinazione, alto impatto e bassa rilevabilità, le rende tra le scoperte più gratificanti nel bug bounty e nel testing di sicurezza delle API.

Come Funziona una Race Condition

Immagina un coupon valido per un solo utilizzo. Normalmente il flusso è:

1. Arriva la richiesta; il server verifica che il coupon non sia stato usato.
2. Il server applica il credito e lo contrassegna come usato.

Ora un attaccante invia 50 richieste di riscatto esattamente nello stesso istante. Se tutte e 50 raggiungono il passaggio 1 prima che una qualsiasi di esse completi il passaggio 2, il server le convalida tutte sullo stesso stato "non usato" e applica il credito 50 volte.

Verifica Condizione

→finestra minima

L'Attaccante Altera lo Stato

→

Usa Risultato Obsoleto

La logica era corretta per una richiesta alla volta, ma si è rotta sotto concorrenza. Quel divario, tra controllo e utilizzo, è dove vive l'attacco.

Dove Compaiono le Race Condition

Come Testarle

Individua le azioni a uso singolo o limitate, poi lancia molte richieste identiche nel modo più simultaneo possibile. Il Repeater di Burp Suite può inviare un gruppo di richieste in parallelo, e un breve script Python che usa richieste async può fare lo stesso.

Come Prevenirle

Difendersi dalle race condition significa eliminare il presupposto di un ordine di esecuzione sicuro:

• Locking: mutex, semafori o lock a livello di riga del database, così che una sola operazione tocchi la risorsa alla volta.
• Operazioni atomiche: combina il controllo e l'azione in un unico passaggio indivisibile.
• Idempotency key: garantiscono che una richiesta ripetuta abbia effetto una sola volta.
• Vincoli del database: unicità, optimistic locking (numeri di versione) o SELECT ... FOR UPDATE.

Le race condition premiano gli hunter che comprendono un'applicazione abbastanza a fondo da sapere quali azioni dovrebbero avvenire una sola volta, e poi dimostrano che, sotto pressione, avvengono di più.