Der Kampf um Millisekunden
Race Conditions entstehen nicht durch klassische „Fehler im Code“, sondern durch Zeitabläufe. Angreifer nutzen gezielt die winzigen Lücken zwischen Prüfung und Nutzung aus. Schon Millisekunden entscheiden darüber, ob eine Aktion einmal oder mehrfach ausgeführt wird.
TOCTOU – Time of Check to Time of Use
Das bekannteste Muster ist TOCTOU (Time of Check to Time of Use):
- Das System prüft eine Bedingung („Hat der Nutzer noch Guthaben?“).
- Das System führt danach eine Aktion aus („Buchung ausführen“).
Wenn zwischen diesen beiden Schritten eine Zeitlücke existiert, kann ein Angreifer mehrere Requests gleichzeitig losschicken. Jeder Request sieht den alten Zustand, obwohl er sich gleich ändern wird.
Beispiel:
- Guthaben = 100 €.
- Zwei gleichzeitige Requests prüfen: „Genug Guthaben vorhanden.“
- Beide Bestellungen werden genehmigt.
- Guthaben wird nur einmal abgezogen.
Techniken für Race-Condition-Angriffe
1. Gleichzeitige Requests
Angreifer schicken viele identische Requests parallel.
- Tools wie Burp Suite Intruder oder Turbo Intruder ermöglichen hunderte Requests in Millisekunden.
- Ziel: Zwei oder mehr Requests durchlaufen den Prüfungs- und Ausführungsschritt fast gleichzeitig.
2. Verzögerungen provozieren
Manchmal sind Systeme zu schnell für „normale“ Race Conditions. Angreifer nutzen dann künstliche Verzögerungen:
- Absichtlich langsame Netzwerkverbindungen.
- Große Payloads, die den Server belasten.
- Timing-Angriffe, die die Ausführungszeit beeinflussen.
So lässt sich das Fenster zwischen „Check“ und „Use“ vergrößern.
3. GET vs. POST vs. API
Race Conditions sind nicht auf eine Methode beschränkt. Angreifer testen:
- Web-Formulare (POST).
- API-Endpunkte (REST/GraphQL).
- Mobile App-Requests (oft noch schlechter abgesichert).
Überall dort, wo dieselbe Ressource mehrfach gleichzeitig angefragt werden kann, besteht Risiko.
Beispiel: Gutschein doppelt einlösen
Ein Online-Shop prüft bei Gutscheinen so:
- Check: Ist der Gutschein gültig?
- Einlösen: Gutschein als „verbraucht“ markieren.
Ein Angreifer sendet zwei Requests gleichzeitig:
- Beide sehen „gültig“.
- Beide lösen denselben Gutschein ein.
- Ergebnis: Der Rabatt wird doppelt angerechnet.
Warum Browser und APIs anfällig sind
Das Problem wird durch moderne Architekturen verstärkt:
- Asynchrone Systeme: Microservices und APIs reagieren nicht immer gleichzeitig.
- Cloud-Umgebungen: Mehrere Serverinstanzen verarbeiten Requests parallel – Synchronisation ist schwierig.
- Hohe Last: Unter Stress-Situationen treten Race Conditions häufiger auf.
Grenzen der Same-Origin-Policy
Manche denken: „Browser schützen doch mit Same-Origin-Policy.“
Falsch – die SOP schützt nur vor unbefugtem Lesen von Antworten. Race Conditions nutzen den normalen Request-Fluss – der ist völlig legitim.
Was du mitnehmen solltest
- Race-Condition-Angriffe basieren auf gleichzeitigen Requests.
- Das TOCTOU-Muster (Check vs. Use) ist der Klassiker.
- Angreifer nutzen Tools, Verzögerungen und parallele Requests, um die Zeitfenster zu treffen.
- Besonders gefährdet: Gutscheine, Guthaben, Banking-Transaktionen, API-Endpunkte.
Im nächsten Teil schauen wir uns reale Beispiele und Auswirkungen an – von doppelten Überweisungen bis zu Bug-Bounty-Reports mit fünfstelligen Belohnungen.
Schreibe einen Kommentar