Race Condition

Eine Race Condition ist ein zeitlicher Fehler. Sie tritt auf, wenn eine Anwendung annimmt, dass Operationen nacheinander ablaufen, ein Angreifer sie aber zwingt, gleichzeitig zu erfolgen. Die klassische Form ist eine Time-of-Check-to-Time-of-Use-Lücke (TOCTOU): Die Anwendung prüft eine Bedingung (hat dieser Gutschein noch Guthaben?) und reagiert dann darauf (schreibt das Guthaben gut), und der Angreifer quetscht zusätzliche Aktionen in das Fenster zwischen den beiden Schritten.

Warum es wichtig ist

Race Conditions sind gerade deshalb gefährlich, weil jede einzelne Anfrage legitim ist, sodass sie eingabefokussierten Werkzeugen entgehen, genau wie Business-Logic-Schwachstellen es tun. Sie sind außerdem nicht deterministisch: Derselbe Code kann sich tausende Male korrekt verhalten und katastrophal versagen, wenn das Timing zusammenpasst. Das bedeutet, dass herkömmliche sequenzielle Tests sie fast nie auslösen. Diese Kombination, hohe Auswirkung und geringe Auffindbarkeit, macht sie zu einigen der lohnendsten Funde im Bug Bounty und beim API-Security-Testing.

Wie eine Race Condition funktioniert

Stell dir einen Gutschein vor, der eine Einlösung wert ist. Normalerweise sieht der Ablauf so aus:

1. Eine Anfrage trifft ein; der Server prüft, dass der Gutschein unbenutzt ist.
2. Der Server schreibt das Guthaben gut und markiert ihn als benutzt.

Nun sendet ein Angreifer 50 Einlöseanfragen zu exakt demselben Zeitpunkt. Wenn alle 50 Schritt 1 erreichen, bevor eine davon Schritt 2 abschließt, validiert der Server sie alle gegen denselben "unbenutzten" Zustand und schreibt das Guthaben 50 Mal gut.

Bedingung prüfen

→winziges Fenster

Angreifer verändert Zustand

→

Veraltetes Ergebnis nutzen

Die Logik war für jeweils eine Anfrage korrekt, brach aber unter Nebenläufigkeit zusammen. Diese Lücke, zwischen Prüfung und Nutzung, ist der Ort, an dem der Angriff stattfindet.

Wo Race Conditions auftreten

So testet man

Finde Aktionen mit Einmalnutzung oder mit Begrenzung und feuere dann viele identische Anfragen so gleichzeitig wie möglich ab. Der Burp Suite Repeater kann eine Gruppe von Anfragen parallel senden, und ein kurzes Python-Skript mit asynchronen Anfragen kann dasselbe leisten.

Wie man sie verhindert

Race Conditions abzuwehren bedeutet, die Annahme einer sicheren Ausführungsreihenfolge zu beseitigen:

• Locking: Mutexe, Semaphore oder Datenbank-Zeilensperren, sodass immer nur eine Operation zur Zeit auf die Ressource zugreift.
• Atomare Operationen: fassen die Prüfung und die Aktion zu einem einzigen, unteilbaren Schritt zusammen.
• Idempotenzschlüssel: stellen sicher, dass eine wiederholte Anfrage nur einmal wirksam wird.
• Datenbankbeschränkungen: Eindeutigkeit, optimistisches Locking (Versionsnummern) oder SELECT ... FOR UPDATE.

Race Conditions belohnen Hunter, die eine Anwendung gründlich genug verstehen, um zu wissen, welche Aktionen nur einmal stattfinden sollten, und dann beweisen, dass sie unter Druck öfter stattfinden.