Race Conditions entstehen, wenn zwei oder mehr Abläufe gleichzeitig auf dieselbe Ressource zugreifen und das Ergebnis von der zeitlichen Reihenfolge der Operationen abhängt. Beispielsweise können zwei parallele Anfragen denselben Gutschein einlösen, wenn beide den Status «noch nicht verwendet» prüfen, bevor eine der Anfragen die Einlösung in der Datenbank speichert.

Die Folge: In sicherheitsrelevanten Anwendungen können dadurch Autorisierungen, Zugriffskontrollen oder Integritätsmechanismen umgangen werden. Race Conditions können somit erhebliche Sicherheits- und Geschäftsrisiken verursachen und sollten daher im Rahmen einer umfassenden Cybersecurity-Strategie berücksichtigt werden.

Dieser Artikel gibt eine Einführung in das Konzept der Race Conditions mit Fokus auf die sicherheitstechnischen Aspekte. Sie erfahren wie Race Conditions entstehen, welche typischen Angriffsflächen sie in Web-Backends und lokalen Komponenten bieten, mit welchen Architektur- und Prozessmassnahmen sie sich verhindern lassen und mit welcher Prüfstrategie sich diese Fehler im Rahmen von Security Assessments und Code Reviews systematisch identifizieren lassen.

Einführung zu Race Conditions

Parallelität gehört heute zur Standardarchitektur moderner Software. Asynchrone Ereignisse, Multithreading, Microservices, Container-Orchestrierung und cloudbasierte Skalierung sorgen dafür, dass mehrere Ausführungsstränge parallel oder quasi parallel auf Zustände zugreifen.

Während Entwickler häufig von einer stabilen Abfolge einzelner Verarbeitungsschritte ausgehen, zerlegt das Betriebssystem die Programmlogik in unterbrechbare Schritte. Jeder dieser Schritte kann durch Scheduling oder I/O-Wartezeiten verzögert werden. Dadurch kann zwischen der Prüfung einer Annahme und ihrer anschliessenden Nutzung ein Zeitfenster entstehen, in dem sich der zugrunde liegende Zustand verändert. Genau in diesem zeitlichen Fenster entstehen Race Conditions.

Sicherheitsrelevant wird eine Race Condition dann, wenn dadurch eine Annahme verletzt wird, die das System eigentlich jederzeit garantieren müsste. Das kann beispielsweise bedeuten, dass ein Benutzer mehr Guthaben ausgeben kann, als vorhanden ist, ein Token mehrfach verwendet wird oder eine Berechtigungsprüfung auf einem veralteten Zustand basiert.

Wichtige Begriffe rund um Race Conditions

Um Race Conditions richtig einordnen und ihre Auswirkungen verstehen zu können, lohnt sich zunächst ein Blick auf einige zentrale Begriffe.

• Invariante: Eine Regel, die im System jederzeit gelten muss. Beispiele sind: Ein Gutschein darf nur einmal eingelöst werden, ein Token darf nach der Verwendung nicht erneut akzeptiert werden oder ein Benutzer darf nur auf eigene Daten zugreifen.
• Atomare Operation: Eine Operation, die aus Sicht des Systems ganz oder gar nicht ausgeführt wird. Entscheidend ist, dass zwischen Prüfung und Zustandsänderung kein anderer paralleler Ablauf denselben Zustand widersprüchlich verändern kann.
• Synchronisation: Technische Koordination paralleler Zugriffe, beispielsweise durch Locks, Transaktionen oder andere Mechanismen, die gleichzeitige widersprüchliche Änderungen verhindern.
• Transaktionale Einheit: Ein zusammenhängender Ablauf, bei dem mehrere Schritte gemeinsam ausgeführt werden. Entweder werden alle Schritte erfolgreich abgeschlossen oder keiner davon wird dauerhaft wirksam.
• Constraint: Eine durch das System erzwungene Regel, häufig auf Datenbankebene. Ein eindeutiger Constraint kann zum Beispiel verhindern, dass derselbe Gutschein mehrfach als eingelöst gespeichert wird.
• Idempotenz: Eine Eigenschaft von Operationen, bei der eine wiederholte Ausführung denselben Effekt hat wie eine einmalige Ausführung. Das ist besonders relevant, wenn Requests wiederholt, parallel oder nach einem Fehler erneut gesendet werden.
• Konsistenzfenster: Ein kurzer Zeitraum, in dem verschiedene Systemteile unterschiedliche Zustände sehen, etwa aufgrund von Replikationsverzögerungen oder asynchroner Verarbeitung.
• Time of Check to Time of Use (TOCTOU): Eine Unterkategorie von Race Conditions, bei der eine sicherheitsrelevante Prüfung im Programmablauf durchgeführt und das Ergebnis unmittelbar danach zur Entscheidung herangezogen wird. Das System befindet sich zwischen diesen beiden Zeitpunkten nicht in einem eingefrorenen Zustand. Ein anderer Prozess oder ein paralleler Request kann den Zustand verändern, sodass die ursprüngliche Prüfung für die anschliessende Aktion bereits veraltet ist.
• Data Race: Dieser in der Parallelprogrammierung verwendete Begriff beschreibt gleichzeitige Zugriffe auf dieselbe Variable ohne ausreichende Synchronisation, insbesondere wenn mindestens ein Zugriff den Wert verändert. Zunächst führt dies oft «nur» zu falschem oder unvorhersehbarem Programmverhalten, etwa weil ein Zähler falsch berechnet oder ein Zustand inkonsistent wird. Darüber hinaus können Data Races je nach Programmiersprache und Kontext auch zu Abstürzen, Speicherfehlern oder sicherheitsrelevanten Schwachstellen führen; in Sprachen wie C und C++ können sie sogar undefiniertes Verhalten verursachen.

Race Conditions betreffen das gesamte Unternehmen

Race Conditions betreffen nicht nur Entwicklerteams, sondern können direkt geschäftskritische Prozesse beeinflussen. In der Praxis treten sie häufig dort auf, wo mehrere Aktionen gleichzeitig verarbeitet werden – etwa in Bezug auf Gutscheine, Zahlungen, Freigaben, Passwort-Resets, Rollenwechsel oder Bestandsführung. Der daraus resultierende Schaden geht daher schnell auf Business-Ebene über: doppelte Einlösungen, unberechtigte Aktionen, fehlerhafte Buchungen oder schwer nachvollziehbare Ausnahmesituationen im Betrieb.

Hinzu kommt ein Governance-Problem. Klassische Kontrollfragen wie «Werden Berechtigungen vor dem Zugriff geprüft? » reichen in Hinsicht auf Race Conditions nicht aus. Entscheidend ist nicht, ob eine Prüfung erfolgt, sondern ob die gewünschte Regel technisch erzwungen wird. Eine sauber wirkende Prozessbeschreibung kann daher trügerisch sein, wenn die Durchsetzung nur logisch, aber nicht atomar implementiert ist.

Die Schwierigkeit für Unternehmen: Race Conditions erscheinen oft nicht als offensichtliche Schwachstellen. Viele Fehler zeigen sich erst unter hoher Last, bei parallelen Zugriffen oder in seltenen Betriebszuständen. Automatisierte Prüfwerkzeuge und klassische Code-Checks können Race Conditions daher nur eingeschränkt erkennen. Gerade deshalb werden sie in herkömmlichen Tests oder im regulären Betrieb leicht übersehen, obwohl sie im Ernstfall erhebliche Auswirkungen auf Sicherheit, Geschäftsprozesse und Datenintegrität haben können.

Ursachen und Wirkungsketten

Race Conditions entstehen typischerweise durch das Zusammenspiel von drei Faktoren:

1. Unterbrechbare Ausführung: Nahezu jeder Programmabschnitt kann während der Ausführung unterbrochen werden. Dadurch kann das System zwischen einer Prüfung und der anschliessenden Nutzung beliebige andere Aktivitäten ausführen.
2. Nicht atomare Operationen: Viele Standardoperationen bestehen intern aus mehreren einzelnen Schritten. Besonders problematisch ist ein Ablauf, bei dem zunächst geprüft wird, ob eine bestimmte Bedingung erfüllt ist, und der Zustand erst danach verändert wird. Zwischen diesen beiden Schritten kann ein anderer Vorgang eingreifen und den Zustand verändern.
3. Zeitweilige Inkonsistenzen in verteilten Systemen: In replizierten oder asynchron verarbeiteten Systemen werden Daten häufig nicht überall gleichzeitig aktualisiert, wodurch Datenbestände kurzfristig voneinander abweichen können. Dadurch kann es vorkommen, dass zwei Anfragen zur gleichen Zeit unterschiedliche Datenstände sehen.

Eine im Code sichtbare, logisch saubere Sequenz ist deshalb keine Garantie für eine reale, ununterbrochene Ausführung.

Beispiel aus der Anwendungsebene

Ein einfaches Beispiel aus der Anwendungsebene veranschaulicht dies: Ein Endpunkt prüft, dass ein Gutschein noch nicht eingelöst wurde, wendet den Rabatt an und markiert den Gutschein erst danach in der Datenbank als verbraucht. Wenn ein und derselbe Gutschein bei zwei parallelen Anfragen als nicht eingelöst angezeigt wird, kann er doppelt eingelöst werden.

Dieses Beispiel zeigt, dass Sicherheit nicht allein durch eine vorgelagerte Prüfung gewährleistet wird, sondern durch Operationen, bei denen Prüfung und Zustandsänderung atomar miteinander verbunden sind.

Angriffsoberflächen in der Praxis

Auf Web-Ebene treten Race Conditions vor allem in Workflows auf, die sich über mehrere Anfragen oder Verarbeitungsschritte hinweg erstrecken. Dazu gehören:

• Passwort-Reset-Flows und E-Mail-Verifikationen, bei denen Tokens nicht atomar entwertet werden
• Gutschein- und Kreditlogiken ohne eindeutige Constraints – also wenn nicht sichergestellt ist, dass eine Aktion nur einmal ausgeführt werden kann
• Rollen- oder Besitzwechsel, wenn zunächst nur die Berechtigung geprüft wird und der eigentliche Zugriff erst später erfolgt
• Auch lokale Komponenten können betroffen sein, wenn eine Anwendung eine Annahme prüft und später erneut auf denselben logischen Zustand zugreift

Das Problem betrifft nicht nur bestimmte Programmiersprachen. Entscheidend ist vielmehr das zugrunde liegende Muster: Ein Zustand wird zunächst nur geprüft und erst später verwendet. Wenn sich dieser Zustand zwischen den beiden Zeitpunkten verändert, kann das System eine falsche Entscheidung treffen.

In verteilten Systemen werden Race Conditions zusätzlich dadurch verstärkt, dass Daten nicht immer sofort überall aktualisiert werden. Durch diese Verzögerungen können kurzzeitig widersprüchliche Datenstände entstehen, die gezielt abgefragt oder verändert werden. Werden diese gezielt ausgenutzt, können Aktionen durchgeführt werden, die eigentlich nicht mehr erlaubt sein sollten. Die Auswirkungen können jedoch bereits eingetreten sein, bevor das System den Fehler erkennt.

Exploitierbarkeit und Nachweisbarkeit

In einem Penetration Test ist eine Race Condition dann verwertbar, wenn:

• ein relevantes Sicherheitsziel betroffen ist,
• das zeitliche Fenster zuverlässig getroffen werden kann und
• ein eindeutiges Artefakt den Erfolg belegt.

Ein relevantes Ziel liegt vor, wenn die Grundwerte Vertraulichkeit, Integrität oder Verfügbarkeit (Confidentiality, Integrity, Availability; CIA) verletzt werden.

Das zeitliche Fenster lässt sich selten durch exaktes Timing treffen, wohl aber durch Parallelisierung und Wiederholung. In der Praxis genügen häufig viele gleichzeitige Anfragen mit kleinem, zufälligem Zeitabstand, um den kritischen Punkt statistisch zu erreichen.

Für die Bewertung aus Unternehmenssicht ist wichtig, dass die Nachweisbarkeit messbar ist. Messbare Effekte können doppelte Einlösungen von Einmal-Tokens, fehlerhafte Buchungen, unzulässige Statuswechsel oder Protokolleinträge sein, die den Eintritt eines verbotenen Zustands dokumentieren.

Der Nachweis ist dabei nicht nur eine Frage des Timings, sondern auch der Prüfstrategie. Je klarer der unerlaubte Zustand definiert wird und je eindeutiger das erwartete Artefakt ist, desto belastbarer wird der Befund.

Gegenmassnahmen zu Race Conditions

Race Conditions können zu erheblichen Sicherheitsproblemen führen. Deshalb sind geeignete Gegenmassnahmen notwendig, um kritische Abläufe zuverlässig abzusichern.

Warum klassische Kontrollen oft nicht reichen

Kurze Zeitfenster sind kein Schutz. Scheduler, I/O-Wartezeiten, Hintergrundprozesse und Netzwerklatenzen reichen bereits im Millisekundenbereich aus, damit eine Race Condition statistisch getroffen werden kann.

Auch der Verweis auf «zusätzliche Prüfungen» greift häufig zu kurz. Wird eine fachliche Regel nur mehrfach geprüft, aber nicht technisch erzwungen, bleibt die Schwachstelle bestehen. Das gilt insbesondere dann, wenn mehrere Systeme, Services oder Requests beteiligt sind.

Selbst Datenbanktransaktionen sind kein Allheilmittel, wenn die fachliche Einmaligkeit nicht durch geeignete Constraints abgesichert ist. Entscheidend ist nicht die Anzahl der Schutzmechanismen, sondern ob die Sicherheitsinvariante an der richtigen Stelle verbindlich durchgesetzt wird.

Was robuste Gegenmassnahmen ausmacht

Wirksame Gegenmassnahmen erzwingen die gewünschte Invariante technisch. Auf Datenbankebene sind eindeutige Constraints, atomare Updates und Idempotenzschlüssel zentrale Bausteine. Auf Anwendungsebene sollten kritische Zustandswechsel so modelliert werden, dass fachliche Regeln nicht nur geprüft, sondern in derselben Operation durchgesetzt werden.

Ebenso wichtig ist die Architekturperspektive. Sicherheitsregeln sollten dort implementiert werden, wo sie verbindlich durchgesetzt werden können, etwa im Datenbankschema oder in atomaren Systemoperationen, und nicht nur in vorgelagerten Plausibilitätsprüfungen. Für das Management bedeutet das, dass Sicherheitsqualität nicht allein durch zusätzliche Tests entsteht, sondern bereits durch Architekturentscheidungen.

Ein weiterer Erfolgsfaktor ist die klare Definition fachlicher Invarianten. Solange unklar bleibt, was «genau einmal», «nur der Eigentümer» oder «nur im freigegebenen Zustand» technisch bedeutet, entstehen leicht Lücken zwischen Fachlogik und Implementierung.

Prüfstrategie in Assessment und Code Review

Race Conditions werden selten mit Einzeltests sichtbar. Aussagekräftige Prüfungen arbeiten mit gezielter Nebenläufigkeit, Parallelisierung, Wiederholung und messbaren Erfolgskriterien. Dabei ist entscheidend, dass nicht nur technische Fehlerbilder gesucht werden, sondern fachliche Regeln als Prüfkriterien dienen.

Im Rahmen eines Penetration Test oder Application Security Assessment ist es daher sinnvoll, besonders kritische Workflows gezielt auf Race Conditions zu untersuchen, beispielsweise Zahlungslogik, Token-Flows, Freigabeprozesse, Berechtigungswechsel oder Bestandsoperationen. Der Mehrwert liegt nicht nur im Nachweis einzelner Schwachstellen, sondern auch in der Identifikation wiederkehrender Designmuster, die in mehreren Systemteilen dasselbe Risiko erzeugen.

Fazit – Race Conditions als Sicherheitsrisiko

Race Conditions sind aus sicherheitstechnischer Perspektive ein strukturelles Problem moderner Software und aus Unternehmenssicht ein Qualitäts- und Geschäftsrisiko mit direktem Bezug zu Kernprozessen. Sie entstehen nicht durch «schlechtes Timing», sondern durch ein Design, das auf stabile Zwischenzustände vertraut, ohne dass diese Stabilität technisch gesichert ist.

Robuste Systeme vermeiden diese Annahme. Sie setzen auf atomare Operationen, eindeutig erzwungene Regeln im Datenmodell und Tests, die Nebenläufigkeit realistisch abbilden. Gerade bei sicherheitskritischen Anwendungen lohnt sich deshalb eine gezielte Prüfung im Rahmen von Application Security Testing und Code Reviews, weil sich damit nicht nur einzelne Fehler finden lassen, sondern auch die Widerstandsfähigkeit zentraler Geschäftsprozesse nachhaltig verbessert werden kann.

Systeme prüfen lassen

Oneconsult bietet verschiedene Möglichkeiten, die Widerstandsfähigkeit Ihrer Anwendungen und Prozesse gegenüber durch Race Conditions bedingten Schwachstellen zu prüfen und gezielt zu verbessern.

Im Bereich Penetration Testing und insbesondere im Application Testing können kritische Web- und API-Workflows methodisch auf Schwachstellen wie fehlerhafte Zustandswechsel, unzureichend abgesicherte Einmaloperationen oder Timing-Probleme untersucht werden.

Ergänzend kann ein Security Assessment helfen, wiederkehrende Risiken auf Architektur- und Prozessebene einzuordnen und geeignete Massnahmen abzuleiten. Für den Wissensaufbau in Entwicklungs- und Security-Teams bietet unsere Cybersecurity Academy praxisnahe Trainings an. Über eine unverbindliche Kontaktaufnahme freuen wir uns: Kontakt aufnehmen.