Teil 1 – Was sind Race Conditions?

Wenn zwei gleichzeitig losrennen

Stell dir vor, zwei Personen wollen denselben Sitzplatz im Kino reservieren. Beide klicken fast zeitgleich auf „Buchen“. Das System prüft bei beiden: „Platz noch frei?“ – und bestätigt. Erst danach wird die Buchung gespeichert. Ergebnis: Zwei Leute haben denselben Platz.
Das ist eine Race Condition: Ein Fehler, der entsteht, wenn mehrere Aktionen gleichzeitig ablaufen und sich gegenseitig beeinflussen.


Definition

Eine Race Condition liegt vor, wenn das Ergebnis einer Operation davon abhängt, welcher Prozess oder Request schneller ausgeführt wird.
Das Problem entsteht durch fehlende Synchronisation beim Zugriff auf dieselbe Ressource – sei es eine Datei, ein Datenbankeintrag oder ein Guthabenwert.

In der IT-Sicherheit nutzen Angreifer Race Conditions aus, indem sie gezielt mehrere Anfragen gleichzeitig senden. So können sie Aktionen doppelt ausführen oder Prüfungen umgehen.


Ein einfaches Beispiel

Ein Online-Shop erlaubt den Kauf mit Guthaben. Der Ablauf:

  1. System prüft: Hat der User genug Guthaben?
  2. Wenn ja, Bestellung wird ausgeführt.
  3. Guthaben wird abgebucht.

Ein Angreifer schickt nun zwei Requests gleichzeitig:

  • Beide sehen Guthaben = 100 €.
  • Beide genehmigen den Kauf.
  • Guthaben wird erst danach abgezogen.

Ergebnis: Zwei Bestellungen für nur 100 € Guthaben.


Typische Szenarien für Race Conditions

  • Banking: Mehrfaches Abheben oder Überweisen von Geld.
  • E-Commerce: Gutscheine oder Rabattcodes mehrfach einlösen.
  • Gaming/Apps: Belohnungen oder Items mehrfach erhalten.
  • Cloud/Provisioning: Ressourcen mehrfach kostenlos anlegen.

Das Muster ist immer gleich: Ein System prüft etwas, nutzt es aber erst später – und in dieser „Zeitlücke“ greifen Angreifer an.


Warum Race Conditions so gefährlich sind

  • Schwer zu entdecken: Im normalen Testbetrieb tritt das Problem oft nicht auf – nur bei gleichzeitigen Requests.
  • Hoher Impact: Angreifer können echtes Geld, Ressourcen oder Daten mehrfach erhalten.
  • Leicht automatisierbar: Mit Tools wie Burp Suite Intruder, Turbo Intruder oder einfachen Scripts lassen sich hunderte Requests gleichzeitig abfeuern.

Abgrenzung zu anderen Schwachstellen

  • Nicht dasselbe wie Broken Access Control: Bei BAC fehlen Berechtigungsprüfungen. Bei Race Conditions ist die Prüfung da – aber mehrere Prozesse nutzen dieselbe Lücke in der Zeit.
  • Nicht dasselbe wie Insecure Design: Das Design kann solide wirken, aber wenn keine Synchronisation vorgesehen ist, öffnet es Tür und Tor für Race Conditions.

Was du mitnehmen solltest

  • Eine Race Condition entsteht, wenn gleichzeitige Requests oder Prozesse unvorhersehbare Effekte haben.
  • Beispiele: doppelte Bestellungen, Mehrfach-Auszahlungen, mehrfach eingelöste Gutscheine.
  • Das macht sie subtil und gefährlich – und oft schwer zu reproduzieren.

Im nächsten Teil schauen wir uns im Detail an, wie Race-Condition-Angriffe funktionieren – inklusive Timing-Manipulationen und dem bekannten TOCTOU-Prinzip (Time of Check to Time of Use).


Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert