Neue Risikokategorie in den OWASP Top Ten: Das Unerwartete erwarten

Mit der Veröffentlichung der Top Ten 2025 durch OWASP stehen Unternehmen vor einigen neuen Risikokategorien, denen sie besondere Aufmerksamkeit schenken sollten – darunter eine völlig neue Kategorie, die ein für alle Mal beweist, dass Unwissenheit tatsächlich schaden kann.

Die neue Kategorie Mishandling of Exceptional Conditions beschreibt, was schiefgehen kann, wenn Unternehmen nicht darauf vorbereitet sind, ungewöhnliche oder unvorhersehbare Situationen zu verhindern, zu erkennen und darauf zu reagieren. Laut OWASP tritt diese Schwachstelle auf, wenn eine Anwendung ungewöhnliche Ereignisse nicht verhindert, Probleme beim Auftreten nicht identifiziert und/oder bei unerwarteten Situationen schlecht oder gar nicht reagiert.

Die Erkenntnis, dass Unternehmen auf das Unerwartete vorbereitet sein müssen, spiegelt die Realität heutiger hochgradig verteilter und vernetzter Systeme wider. Dabei spricht OWASP keineswegs von unbekannten Problemen – die Kategorie „Mishandling of Exceptional Conditions“ umfasst 24 Common Weakness Enumerations (CWEs). Es geht vielmehr darum, dass diese CWEs, die fehlerhafte Fehlerbehandlung, nicht geschlossene Ereignisse, logische Fehler und andere Szenarien beinhalten, unter anormalen Bedingungen auftreten können. Dies kann beispielsweise durch unzureichende Eingabevalidierung, Fehler in übergeordneten Behandlungsfunktionen sowie eine inkonsistente (oder nicht vorhandene) Ausnahmebehandlung entstehen. Wie OWASP feststellt: „Jedes Mal, wenn eine Anwendung sich bei ihrem nächsten Befehl unsicher ist, wurde eine Ausnahmesituation falsch behandelt.“

Solche Ausnahmesituationen können dazu führen, dass Systeme in einen unvorhersehbaren Zustand geraten, was Systemabstürze, unerwartetes Verhalten und langfristige Sicherheitslücken zur Folge hat. Der Schlüssel zur Vermeidung solcher Störungen liegt darin, vom Schlimmsten auszugehen und für den Fall des Unerwarteten gewappnet zu sein.

[VIDEO ANSEHEN]

Ausnahmesituationen und die Entwicklung der Top Ten

Die Zusammensetzung der alle vier Jahre erscheinenden Top-Ten-Liste der schwerwiegendsten Risiken für die Webanwendungssicherheit war über die Jahre hinweg recht stabil; einige Kategorien verschoben sich, und alle vier Jahre kamen ein oder zwei neue hinzu. Die Ausgabe 2025 enthält zwei neue Einträge, darunter „Mishandling of Exceptional Conditions“ auf Platz 10. Der andere, Software Supply Chain Failures, auf Platz 3, ist eine Erweiterung der früheren Kategorie Vulnerable and Outdated Components (Platz 6 im Jahr 2021), die nun ein breites Spektrum an Software-Kompromittierungen abdeckt. (Für alle, die mitzählen: Broken Access Control bleibt weiterhin das Risiko Nummer 1).

Die Ausnahmesituationen, die diese neueste Kategorie bilden, können eine Vielzahl von Schwachstellen hervorrufen – von Logikfehlern bis hin zu Überläufen sowie betrügerischen Transaktionen bis hin zu Problemen bei Speicher, Timing, Authentifizierung, Autorisierung und anderen Faktoren. Diese Arten von Schwachstellen können die Vertraulichkeit, Verfügbarkeit und Integrität eines Systems oder seiner Daten beeinträchtigen. Sie ermöglichen es einem Angreifer, die fehlerhafte Fehlerbehandlung einer Anwendung auszunutzen, so OWASP.

Ein Beispiel für das Versagen bei der Behandlung unerwarteter Bedingungen ist der Fall, in dem eine Anwendung während eines Denial-of-Service-Angriffs Ausnahmen bei Datei-Uploads erkennt, aber anschließend die Ressourcen nicht freigibt. Wenn dies geschieht, bleiben Ressourcen gesperrt oder nicht verfügbar, was zu einer Ressourcenerschöpfung führt. Wenn ein Angreifer in eine mehrstufige Finanztransaktion eingreift, könnte ein System, das die Transaktion bei Erkennung eines Fehlers nicht zurücksetzt, dem Angreifer ermöglichen, das Konto des Benutzers zu leeren. Wenn während einer Transaktion ein Fehler auftritt, ist es sehr wichtig, „Fail-Closed“ zu agieren – das heißt, die gesamte Transaktion zurückzusetzen und von vorn zu beginnen. Der Versuch, eine Transaktion mitten im Prozess wiederherzustellen, kann zu nicht korrigierbaren Fehlern führen.

Fail Closed vs. Fail Open

Was ist also der Unterschied zwischen diesen beiden Vorgehensweisen? Lassen Sie uns das klären:

Fail Open: Wenn ein System „fail open“ agiert, läuft es weiter oder bleibt „offen“, wenn etwas schiefgeht. Dies ist nützlich, wenn die Aufrechterhaltung des Betriebs oberste Priorität hat, kann jedoch ein Sicherheitsrisiko darstellen.

Fail Closed: Wenn ein System „fail closed“ agiert, schaltet es sich bei einem Problem automatisch ab oder wechselt in einen sicheren Zustand. Dies ist aus Sicherheitsperspektive sicherer, da es hilft, unbefugten Zugriff zu verhindern.

Umgang mit unvorhergesehenen Fehlern

Die Vermeidung dieser Art von Risiko beginnt mit der Planung für das Unbekannte. Dazu gehört, dass man jeden möglichen Systemfehler bei seinem Auftreten erkennen und Schritte zur Problemlösung einleiten kann. Sie müssen in der Lage sein, den Benutzer angemessen zu informieren (ohne kritische Informationen an den Angreifer preiszugeben), das Ereignis zu protokollieren und bei Bedarf einen Alarm auszulösen.

Hier ist ein Beispiel für die Offenlegung eines SQL-Abfragefehlers zusammen mit dem Installationspfad der Website, der zur Identifizierung eines Injection-Punkts verwendet werden kann:

Warnung: odbc_fetch_array() erwartet Parameter /1 als Ressource, erhielt jedoch einen booleschen Wert in D:\app\index_new.php in Zeile 188

Ein System sollte idealerweise über einen globalen Exception-Handler verfügen, um übersehene Fehler abzufangen, sowie über Funktionen wie Monitoring- oder Observability-Tools oder Mechanismen zur Erkennung wiederkehrender Fehlermuster, die auf einen laufenden Angriff hinweisen könnten. Dies hilft bei der Abwehr von Angriffen, die darauf abzielen, Schwachstellen im unternehmensweiten Fehlermanagement auszunutzen.

Für eine standardmäßige Java-Webanwendung lässt sich beispielsweise ein globaler Fehler-Handler auf Ebene des Deployment-Deskriptors web.xml konfigurieren – in diesem Fall über eine Konfiguration, die ab der Servlet-Spezifikation Version 2.5 unterstützt wird.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

Dieser kleine Codeblock weist eine Java-Webanwendung an, wie sie bei unerwarteten internen Problemen reagieren soll. Anstatt Benutzern eine verwirrende Fehlermeldung oder einen leeren Bildschirm anzuzeigen, wird das Problem diskret abgefangen und der Nutzer auf eine benutzerdefinierte Fehlerseite weitergeleitet – in diesem Fall error.jsp.

Da die Konfiguration auf allgemeine java.lang.Exception-Typen ausgelegt ist, fungiert sie als zentraler Fehler-Handler für die gesamte Anwendung. Das bedeutet, dass Nutzer unabhängig vom Ort des Fehlers immer auf dieselbe konsistente und benutzerfreundliche Fehlerseite geleitet werden, anstatt technische Details zu sehen.

Das Unerwartete verhindern

Idealerweise sollten Unternehmen Ausnahmesituationen so weit wie möglich von vornherein verhindern. Die Implementierung von Ratenbegrenzungen, Ressourcenkontingenten, Drosselungen und anderen Limits kann beispielsweise vor Denial-of-Service- und Brute-Force-Angriffen schützen. Identische, wiederkehrende Fehler sollten lediglich statistisch erfasst werden, damit sie das automatisierte Logging und Monitoring nicht beeinträchtigen. Ein System sollte zudem Folgendes umfassen:

Strenge Eingabevalidierung, um sicherzustellen, dass nur korrekt formatierte und bereinigte Daten in den Workflow gelangen. Dies sollte frühzeitig im Datenfluss erfolgen, idealerweise direkt beim Empfang der Daten.

Best Practices für die Fehlerbehandlung, um Fehler direkt an ihrem Entstehungsort abzufangen. Sie sollten effizient gehandhabt werden: Informieren Sie Benutzer klar, führen Sie Protokolle und senden Sie bei Bedarf Warnmeldungen. Ein globaler Fehler-Handler ist zudem ideal, um alle verbleibenden Fehler zu erfassen.

Allgemeine Transaktionssicherheit, ist ebenfalls ein Muss. Arbeiten Sie immer nach dem Prinzip „Fail Closed“: Wenn etwas schiefgeht, führen Sie ein Rollback der gesamten Transaktion durch. Versuchen Sie niemals, eine Transaktion nur teilweise zu reparieren – dies kann zu größeren Problemen führen.

Zentralisiertes Logging, Monitoring und Alerting, zusammen mit einem globalen Exception-Handler, ermöglichen eine schnelle Untersuchung von Vorfällen und einen einheitlichen Prozess zur Ereignisbehandlung, während gleichzeitig Compliance-Anforderungen leichter erfüllt werden können.

Bedrohungsmodellierung und/oder sichere Design-Reviews, die bereits in der Entwurfsphase von Projekten durchgeführt werden.

Code-Reviews oder statische Analysen, sowie Stress-, Performance- und Penetrationstests, die am fertigen System durchgeführt werden.

Der unsachgemäße Umgang mit Ausnahmesituationen mag eine neue Kategorie sein, basiert jedoch auf grundlegenden Prinzipien der Cybersicherheit. Er unterstreicht, warum Unternehmen auf das Unvorhersehbare vorbereitet sein müssen. Auch wenn Sie nicht wissen, welche Form Ausnahmesituationen annehmen werden, ist sicher, dass sie eintreten. Der Schlüssel liegt darin, alle auf die gleiche Weise zu behandeln, um sie bei ihrem unvermeidlichen Auftreten leichter erkennen und darauf reagieren zu können.

Hinweis für Nutzer des SCW Trust Score™ :

Während wir unsere Lernplattform-Inhalte an den OWASP Top 10 2025 Standard anpassen, könnten Sie geringfügige Änderungen am Trust Score Ihrer Full-Stack-Entwickler feststellen. Bitte wenden Sie sich bei Fragen oder Unterstützungsbedarf an Ihren Customer Success Manager.