A10:2025 – Fehlerhafte Behandlung von Ausnahmezuständen

Hintergrund.

Fehlerhafte Behandlung von Ausnahmezuständen ist eine neue Kategorie für 2025. Diese Kategorie enthält 24 CWEs und konzentriert sich auf unsachgemäße Fehlerbehandlung, logische Fehler, „Failing Open" sowie andere verwandte Szenarien, die aus abnormalen Zuständen resultieren, mit denen Systeme konfrontiert werden können. Einige der enthaltenen CWEs waren zuvor der schlechten Codequalität zugeordnet. Das war uns zu allgemein; nach unserer Einschätzung bietet diese spezifischere Kategorie eine bessere Orientierung.

Bemerkenswerte CWEs in dieser Kategorie: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-234 Failure to Handle Missing Parameter, CWE-274 Improper Handling of Insufficient Privileges, CWE-476 NULL Pointer Dereference und CWE-636 Not Failing Securely ('Failing Open').

Beurteilungskriterien.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
24	20.67%	2.95%	100.00%	37.95%	7.11	3.81	769,581	3,416

Beschreibung.

Fehlerhafte Behandlung von Ausnahmezuständen in Software tritt auf, wenn Programme außergewöhnliche und unvorhersehbare Situationen weder verhindern, erkennen noch darauf reagieren – was zu Abstürzen, unerwartetem Verhalten und mitunter zu Schwachstellen führt. Dies kann einen oder mehrere der folgenden drei Mängel umfassen: Die Anwendung verhindert eine ungewöhnliche Situation nicht, sie erkennt sie nicht, während sie eintritt, und/oder sie reagiert anschließend unzureichend oder gar nicht darauf.

Ausnahmezustände können durch fehlende, mangelhafte oder unvollständige Eingabevalidierung entstehen, durch späte oder übergeordnete Fehlerbehandlung anstatt dort, wo die Fehler auftreten, durch unerwartete Umgebungszustände wie Speicher-, Berechtigungs- oder Netzwerkprobleme, inkonsistente Ausnahmebehandlung oder vollständig unbehandelte Ausnahmen, die das System in einen unbekannten und unvorhersehbaren Zustand versetzen. Jedes Mal, wenn eine Anwendung über ihre nächste Anweisung unsicher ist, wurde ein Ausnahmezustand fehlerhaft behandelt. Schwer auffindbare Fehler und Ausnahmen können die Sicherheit der gesamten Anwendung über lange Zeit gefährden.

Bei fehlerhafter Behandlung von Ausnahmezuständen können vielfältige Schwachstellen entstehen, wie logische Fehler, Überläufe, Race Conditions, betrügerische Transaktionen oder Probleme mit Speicher, Zustand, Ressourcen, Timing, Authentifizierung und Autorisierung. Diese Schwachstellen können die Vertraulichkeit, Verfügbarkeit und/oder Integrität eines Systems oder seiner Daten beeinträchtigen. Angreifer:innen nutzen die fehlerhafte Fehlerbehandlung einer Anwendung aus, um diese Schwachstelle auszunutzen.

Prävention und Gegenmaßnahmen.

Um Ausnahmezustände korrekt zu behandeln, müssen wir solche Situationen einplanen (vom Schlimmsten ausgehen). Wir müssen jeden möglichen Systemfehler direkt an der Stelle abfangen, an der er auftritt, und ihn dann behandeln (d. h. etwas Sinnvolles tun, um das Problem zu lösen und die Wiederherstellung sicherzustellen). Als Teil der Behandlung sollten wir einen Fehler werfen (um die/den Benutzer:in verständlich zu informieren), das Ereignis protokollieren sowie bei Bedarf einen Alarm auslösen. Wir sollten außerdem einen globalen Exception-Handler einrichten, für den Fall, dass uns etwas entgangen ist. Idealerweise verfügen wir zusätzlich über Monitoring- und/oder Observability-Werkzeuge, die auf wiederholte Fehler oder Muster hinweisen, die auf einen laufenden Angriff hindeuten, und eine Reaktion, Abwehr oder Blockierung auslösen können. Dies hilft uns, Skripte und Bots zu blockieren und darauf zu reagieren, die unsere Schwachstellen in der Fehlerbehandlung ausnutzen.

Das Abfangen und Behandeln von Ausnahmezuständen stellt sicher, dass die zugrunde liegende Infrastruktur unserer Programme nicht mit unvorhersehbaren Situationen allein gelassen wird. Befindet man sich mitten in einer Transaktion jeglicher Art, ist es äußerst wichtig, die gesamte Transaktion zurückzusetzen und neu zu beginnen (auch bekannt als „Failing Closed"). Der Versuch, eine Transaktion mittendrin wiederherzustellen, ist oft der Punkt, an dem unbehebbare Fehler entstehen.

Wo immer möglich sollten Rate Limiting, Ressourcenkontingente, Throttling und andere Begrenzungen eingesetzt werden, um Ausnahmezustände von vornherein zu verhindern. Nichts in der Informationstechnologie sollte unbegrenzt sein, da dies zu mangelnder Anwendungsresilienz, Denial-of-Service, erfolgreichen Brute-Force-Angriffen und enormen Cloud-Kosten führt.

Es sollte überlegt werden, ob identische, sich wiederholende Fehler ab einer bestimmten Rate nur noch als Statistik ausgegeben werden sollten, die anzeigt, wie oft und in welchem Zeitraum sie aufgetreten sind. Diese Information sollte an die ursprüngliche Meldung angehängt werden, um automatisiertes Logging und Monitoring nicht zu beeinträchtigen, siehe A09:2025 Unzureichendes Sicherheitslogging und Alarmierung.

Darüber hinaus sollten wir strikte Eingabevalidierung (mit Bereinigung oder Escaping potenziell gefährlicher Zeichen, die wir akzeptieren müssen) sowie zentralisierte Fehlerbehandlung, Logging, Monitoring und Alerting mit einem globalen Exception-Handler einsetzen. Eine Anwendung sollte nicht mehrere Funktionen zur Behandlung von Ausnahmezuständen haben – dies sollte einheitlich an einer Stelle erfolgen. Wir sollten zudem Sicherheitsanforderungen für alle Empfehlungen dieses Abschnitts definieren, Bedrohungsmodellierung und/oder sichere Design-Reviews in der Entwurfsphase durchführen, Code-Reviews oder statische Analysen vornehmen sowie Stress-, Performance- und Penetrationstests am fertigen System ausführen.

Wenn möglich, sollte die gesamte Organisation Ausnahmezustände einheitlich behandeln, da dies die Überprüfung und Auditierung des Codes auf Fehler in dieser wichtigen Sicherheitsmaßnahme erleichtert.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1: Ressourcenerschöpfung durch fehlerhafte Behandlung von Ausnahmezuständen (Denial of Service) kann auftreten, wenn die Anwendung beim Datei-Upload Ausnahmen abfängt, die Ressourcen danach jedoch nicht ordnungsgemäß freigibt. Jede neue Ausnahme hinterlässt gesperrte oder anderweitig nicht verfügbare Ressourcen, bis alle Ressourcen verbraucht sind.

Szenario Nr. 2: Offenlegung sensibler Daten durch fehlerhafte Behandlung von Datenbankfehlern, die den vollständigen Systemfehler an die/den Benutzer:in weitergeben. Die/Der Angreifer:in erzwingt weiterhin Fehler, um die sensiblen Systeminformationen für einen gezielteren SQL-Injection-Angriff zu nutzen. Die sensiblen Daten in den Fehlermeldungen dienen dabei als Aufklärung.

Szenario Nr. 3: Zustandskorruption bei Finanztransaktionen kann durch ein:e Angreifer:in verursacht werden, der eine mehrstufige Transaktion durch Netzwerkunterbrechungen stört. Angenommen, die Transaktionsreihenfolge lautet: Nutzerkonto belasten, Zielkonto gutschreiben, Transaktion protokollieren. Wenn das System bei einem Fehler mittendrin die gesamte Transaktion nicht ordnungsgemäß zurücksetzt (Failing Closed), könnte die/der Angreifer:in das Konto der/des Nutzer:in leeren oder über eine Race Condition Geld mehrfach an das Zielkonto senden.

Referenzen.

OWASP MASVS‑RESILIENCE