EMZETT.
Login

Emzett Wiki

Race Conditions und TOCTOU: wenn Timing zur Schwachstelle wird

Properties1
tagsglossar, websicherheit, nebenläufigkeit

2 Min. Lesezeit

Race Conditions und TOCTOU: wenn Timing zur Schwachstelle wird

Kurz: Eine Race Condition entsteht, wenn das Ergebnis vom zufälligen Timing paralleler Abläufe abhängt; bei Prüfung-dann-Nutzung (TOCTOU) kann sich der Zustand dazwischen ändern, etwa bei Gutscheinen, Überweisungen oder Dateien.

Genauer: Wenn zwei Anfragen gleichzeitig dieselben Daten lesen und ändern, kann das Ergebnis falsch werden. Das ist ein Fehler der Nebenläufigkeit und zugleich eine Sicherheitslücke, wenn es Regeln aushebelt (doppelt eingelöster Gutschein, doppelte Auszahlung).

Im Detail

Beispiel: Gutschein einlösen

Anfrage A: liest Gutschein (unbenutzt)      Anfrage B: liest Gutschein (unbenutzt)
A: wendet Rabatt an                          B: wendet Rabatt an
A: setzt Gutschein = benutzt                 B: setzt Gutschein = benutzt

Beide Anfragen sahen „unbenutzt“: der Gutschein wurde zweimal eingelöst. Ebenso: Guthaben doppelt ausgeben, Limits umgehen (Bestellmenge, Likes, Login-Versuche), Rabattcodes, Warenbestand (Überverkauf). Angreifer senden viele parallele Anfragen (Race Window), teils mit HTTP/2-„Single-Packet“-Technik.

TOCTOU bei Dateien und Rechten

Time Of Check to Time Of Use: Erst prüfen (access() erlaubt?), dann nutzen (open()): dazwischen kann jemand die Datei durch einen Symlink auf eine geschützte Datei ersetzen. Ebenso bei temporären Dateien mit vorhersagbarem Namen. Lösung: atomare Operationen (open mit O_EXCL|O_NOFOLLOW, mkstemp), Prüfung am geöffneten Dateideskriptor, nicht am Pfad.

Abwehr

  • Atomare Datenbankoperationen: UPDATE gutscheine SET benutzt = true WHERE id = ? AND benutzt = false und Anzahl betroffener Zeilen prüfen (nur 1 Anfrage gewinnt).
  • Transaktionen mit passender Isolation (SERIALIZABLE) oder Zeilensperren (SELECT … FOR UPDATE), optimistische Sperren (Versionsspalte).
  • Eindeutige Constraints (UNIQUE), Idempotenz-Schlüssel bei Zahlungen/Bestellungen.
  • Mutex/Locks, bei mehreren Servern verteilte Sperren (Redis/DB) mit Vorsicht.
  • Rate Limiting, Warteschlangen (Verarbeitung nacheinander).
  • Nicht auf „erst lesen, dann schreiben“ im Anwendungscode vertrauen.

Testen und Einordnung

  • Parallelen Last-Test (z. B. 50 gleichzeitige Einlösungen) in der eigenen Testumgebung; Tools wie k6, wrk, pytest mit Threads, Burp Turbo Intruder (nur eigene/autorisierte Systeme).
  • Code-Review: Jede Folge „prüfen → ändern“ auf gemeinsamen Daten verdächtig.
  • Datenbank-Integrität (Constraints) ist die letzte Verteidigungslinie.
  • Einordnung: CWE-362/367, Teil von Business-Logic-Fehlern; auch in Betriebssystemen (Dirty COW) und Smart Contracts.
  • Verwandt: Deadlock, Mutex, ACID-Transaktionen, Rate Limiting.

Siehe auch: Datenbank-Transaktionen und ACID, Mutex, Deadlock, Rate Limiting

Backlinks