Das Problem an der Wurzel packen
Race Conditions entstehen, wenn mehrere Prozesse oder Requests gleichzeitig auf dieselbe Ressource zugreifen – ohne klare Koordination. Die Lösung liegt also darin, solche kritischen Abläufe synchron und atomar zu gestalten. Das klingt abstrakt, lässt sich aber mit ein paar erprobten Methoden konkret umsetzen.
Locking-Mechanismen
Eine klassische Methode ist das Sperren von Ressourcen:
- Pessimistisches Locking: Sobald ein Nutzer eine Ressource (z. B. einen Gutschein) anfordert, wird diese sofort gesperrt, bis der Vorgang abgeschlossen ist.
- Optimistisches Locking: Das System geht davon aus, dass Konflikte selten sind. Beim Speichern prüft es, ob sich die Ressource in der Zwischenzeit geändert hat. Falls ja, wird der Vorgang abgebrochen.
Beispiel in SQL:
UPDATE coupons
SET used = 1
WHERE id = 123 AND used = 0;
So kann nur ein Request erfolgreich sein – alle anderen laufen ins Leere.
Idempotenz
Eine Aktion sollte unabhängig davon, wie oft sie ausgeführt wird, immer dasselbe Ergebnis haben.
Beispiele:
- Banking: Eine Überweisung bekommt eine eindeutige Transaktions-ID. Mehrere gleiche Requests führen nicht zu mehrfachen Überweisungen.
- E-Commerce: Ein Gutschein kann nur einmal eingelöst werden – unabhängig davon, wie viele Requests gleichzeitig eingehen.
So wird verhindert, dass Angreifer durch Mehrfach-Requests mehrfach profitieren.
Atomare Operationen
Das gefährliche Zeitfenster entsteht oft, weil Prüfung und Ausführung getrennt sind.
Beispiel (unsicher):
- Prüfen: „Hat Nutzer Guthaben?“
- Bestellung ausführen.
- Guthaben abbuchen.
Besser: Alles in einer atomaren Operation kombinieren.
Beispiel:
UPDATE accounts
SET balance = balance - 100
WHERE user_id = 1 AND balance >= 100;
Hier wird in einem Schritt geprüft und abgebucht.
Rate Limiting und Queueing
Angreifer nutzen oft Tools, um hunderte Requests in Millisekunden abzufeuern. Schutz:
- Rate Limiting: z. B. max. 5 Requests pro Sekunde pro Nutzer.
- Queueing: Requests werden in eine Warteschlange gestellt und nacheinander verarbeitet. So gibt es kein „gleichzeitig“.
Monitoring und Alerts
Auch mit allen Schutzmechanismen sollte man auffällige Muster überwachen:
- Viele identische Requests in sehr kurzer Zeit.
- Wiederholte Fehlversuche bei Gutscheinen oder Transaktionen.
- Log-Einträge mit gleichzeitigen Zugriffen.
So lassen sich Angriffe schnell erkennen und blockieren.
Secure by Design
Am wichtigsten: Race Conditions dürfen nicht erst nachträglich entdeckt werden. Schon beim Design sollte man Abuse Cases bedenken:
- „Was passiert, wenn zwei Leute denselben Gutschein gleichzeitig einlösen?“
- „Kann eine Transaktion doppelt ausgelöst werden?“
Solche Fragen müssen Teil der Architektur-Reviews sein.
Was du mitnehmen solltest
- Schutz vor Race Conditions = Synchronisation und Atomicität.
- Methoden: Locking, Idempotenz, atomare Operationen, Rate Limiting, Monitoring.
- Entwickler müssen von Anfang an Abuse Cases bedenken, nicht erst beim Bugfixing.
Im letzten Teil der Serie werfen wir einen Blick nach vorn: Warum Race Conditions gerade in Zeiten von Microservices, Cloud und APIs immer wichtiger werden – und welche Ressourcen beim Weiterlernen helfen.
Schreibe einen Kommentar