CWE ID: 544
Name: Missing Standardized Error Handling Mechanism

Beschreibung

Das Produkt verwendet keine standardisierte Methode zur Fehlerbehandlung im gesamten Code, was zu inkonsistenter Fehlerbehandlung und daraus resultierenden Schwachstellen führen kann.

Erweiterte Beschreibung

Wenn das Produkt Fehlermeldungen einzeln und isoliert behandelt, ist dies wahrscheinlich mit inkonsistenter Fehlerbehandlung verbunden. Die Ursachen von Fehlern können verloren gehen. Zudem können unbeabsichtigt detaillierte Informationen über die Ursachen eines Fehlers an den User zurückgegeben werden.

Risikominderungsmaßnahmen

Maßnahme (Architecture and Design)

Effektivität: Unknown
Beschreibung: Hier ist eine Strategie zur Behandlung von Fehlern unterschiedlicher Schweregrade, unter Verwendung von Sprachfunktionen oder externen Paketen, sowie definierte Coding Standards:

Strategie zur Fehlerbehandlung nach Schweregrad

Die Strategie basiert auf der Kategorisierung von Fehlern in verschiedene Schweregrade, um eine angemessene Reaktion zu gewährleisten. Wir definieren folgende Kategorien:

• Fatal Errors (Kritische Fehler): Diese Fehler führen zu einem sofortigen Abbruch der Anwendung oder eines Prozesses. Sie sind in der Regel unvorhersehbar und können nicht ohne weiteres behoben werden. Beispiele: Speicherfehler, schwerwiegende Datenkorruption.
• High-Severity Errors (Hochkritische Fehler): Diese Fehler beeinträchtigen die Funktionalität erheblich, führen aber nicht zwingend zu einem sofortigen Abbruch. Sie erfordern eine sofortige Aufmerksamkeit und möglicherweise eine Notfallwiederherstellung. Beispiele: Datenbankverbindungsfehler, Authentifizierungsfehler.
• Medium-Severity Errors (Mittelschwere Fehler): Diese Fehler beeinträchtigen die Funktionalität in geringerem Maße und können möglicherweise durch den Benutzer behoben werden oder durch eine alternative Lösung umgangen werden. Beispiele: fehlende Ressourcen, temporäre Netzwerkprobleme.
• Basic Log Events (Grundlegende Log-Ereignisse): Diese Ereignisse sind keine Fehler im eigentlichen Sinne, sondern Informationen über den normalen Betrieb der Anwendung. Sie dienen der Überwachung und dem Debugging.

Technologie und API

Wir nutzen ein etabliertes Logging-Framework, wie z.B. log4j2 (Java), logging (Python) oder ein vergleichbares Package in der verwendeten Programmiersprache. Dieses Framework bietet eine einfache API für das Protokollieren von Ereignissen mit verschiedenen Schweregraden.

• API-Design: Die API sollte folgende Methoden bereitstellen:
  • logFatal(message, exception): Protokolliert einen fatalen Fehler. Die Anwendung sollte in diesem Fall einen kontrollierten Shutdown durchführen.
  • logHighSeverity(message, exception): Protokolliert einen hochkritischen Fehler. Eine Benachrichtigung an das Operations-Team sollte erfolgen.
  • logMediumSeverity(message, exception): Protokolliert einen mittelschweren Fehler. Der Benutzer sollte eine informative Fehlermeldung erhalten.
  • logBasic(message): Protokolliert ein grundlegendes Ereignis. Diese Ereignisse werden für die Überwachung und das Debugging verwendet.
• Exception Handling: Exceptions sollten immer gefangen und mit der entsprechenden log-Methode protokolliert werden. Die Stacktrace sollte ebenfalls protokolliert werden, um die Fehlerursache zu erleichtern.

Coding Standards

• Try-Catch-Blöcke: Code, der potenziell Fehler verursachen kann, muss in try-catch (oder äquivalenten) Blöcken eingeschlossen werden.
• Fehlermeldungen: Fehlermeldungen müssen klar, präzise und für den Benutzer verständlich sein. Technische Details sollten vermieden werden, es sei denn, sie sind für die Fehlerbehebung unerlässlich.
• Logging: Jeder Fehler muss mit dem entsprechenden Schweregrad protokolliert werden. Die Protokolle sollten leicht zugänglich und durchsuchbar sein.
• Vermeidung von “Swallowing” von Exceptions: Exceptions dürfen nicht einfach ignoriert werden. Sie müssen entweder behandelt oder weitergeleitet werden.
• Konsistenz: Die Fehlerbehandlung muss über die gesamte Anwendung konsistent sein.

Beispiel (Java):

try {
    // Code, der einen Fehler verursachen kann
    databaseConnection.executeQuery("SELECT * FROM users");
} catch (SQLException e) {
    logHighSeverity("Fehler beim Abfragen der Datenbank", e);
    // Benachrichtigung an das Operations-Team
    // Möglicherweise eine alternative Lösung anbieten
}

Zusätzliche Überlegungen:

• Monitoring: Die Protokolle sollten an ein Monitoring-System weitergeleitet werden, um frühzeitig auf Fehler reagieren zu können.
• Alerting: Bei hochkritischen Fehlern sollte ein Alert an das Operations-Team ausgelöst werden.
• Dokumentation: Die Fehlerbehandlungsstrategie und die Coding Standards sollten dokumentiert werden.

Diese Strategie zielt darauf ab, eine robuste und wartbare Fehlerbehandlung zu gewährleisten, die sowohl die Benutzererfahrung verbessert als auch die Fehlerbehebung erleichtert.