Extern generierte Fehlermeldung mit sensiblen Informationen

Beschreibung

Extern generierte Fehlermeldung mit sensiblen Informationen ist eine Schwachstelle, die auftritt, wenn ein Produkt eine Operation durchführt, die Diagnose- oder Fehlermeldungen von externen Komponenten auslöst, die nicht direkt von der Anwendung kontrolliert werden. Diese externen Quellen umfassen Programmiersprachen-Interpreter, Datenbank-Engines, Webserver, Betriebssysteme und Drittanbieter-Bibliotheken. Im Gegensatz zu selbstgenerierten Fehlern stammen diese Meldungen von zugrundeliegender Infrastruktur und enthalten oft detaillierte Systeminformationen, von denen Entwickler möglicherweise nicht erwarten, dass sie offengelegt werden. Häufige Beispiele sind PHP-Interpreter-Fehler, die Dateipfade enthüllen, SQL-Datenbankfehler, die Abfragestruktur offenlegen, und Webserver-Fehler, die Softwareversionen und Konfigurationen preisgeben.

Risiko

Extern generierte Fehlermeldungen stellen erhebliche Sicherheitsrisiken dar, weil sie oft detailliertere Systeminformationen enthalten, als Entwickler erwarten. Datenbankfehler können Tabellennamen, Spaltenstrukturen und Abfragelogik enthüllen, die SQL-Injection-Angriffe unterstützen. Interpreter-Fehler legen vollständige Dateisystempfade, Code-Struktur und Konfigurationsdetails offen. Webserver-Fehler können Softwareversionen, Modulkonfigurationen und interne Netzwerkinformationen preisgeben. Diese Meldungen sind besonders gefährlich, weil sie die Fehlerbehandlung auf Anwendungsebene umgehen und Informationen offenlegen können, die der Anwendungscode explizit zu schützen versucht. Angreifer lösen diese Fehler systematisch durch fehlerhafte Eingaben, ungültige Parameter und Randfalleanfragen aus, um Anwendungsinterna vor dem Starten gezielter Angriffe zu kartieren.

Lösung

Konfigurieren Sie alle externen Komponenten, um detaillierte Fehlerausgaben in Produktionsumgebungen zu unterdrücken. Für PHP setzen Sie display_errors = Off und log_errors = On in php.ini. Für Datenbanken konfigurieren Sie Verbindungen, um keine detaillierten Fehlermeldungen an Clients offenzulegen. Implementieren Sie Ausnahmebehandlung auf Anwendungsebene, die Fehler von externen Komponenten abfängt, bevor sie Benutzer erreichen. Konfigurieren Sie Webserver, um benutzerdefinierte Fehlerseiten anstelle von Standardfehlermeldungen zurückzugeben. Verwenden Sie Fehlerbehandlungs-Middleware, die alle Antworten abfängt und sensible Informationen entfernt. Testen Sie Anwendungen regelmäßig, um sicherzustellen, dass externe Komponentenfehler nicht durch Fehlerbehandlungsgrenzen durchsickern. Pflegen Sie konsistente Fehlerbehandlung über alle Deployment-Umgebungen und automatisieren Sie die Sicherheitskonfigurationsüberprüfung.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Vertraulichkeit

Externe Fehlermeldungen legen oft sensible Anwendungsdaten offen, einschließlich Dateipfade, Datenbankstruktur, Konfigurationsdetails und Softwareversionen. Diese Informationen helfen Angreifern bei der Planung und Ausführung gezielter Angriffe gegen die spezifische Implementierung.

Beispielcode

Anfälliger Code (PHP)

Der folgende Code erlaubt externen Komponenten-Fehlermeldungen, Benutzer zu erreichen:

<?php
// php.ini-Einstellung: display_errors = On (ANFÄLLIG)

// Datenbankverbindung mit offengelegten Fehlern
function getUserData($userId) {
    try {
        $conn = new PDO(
            "mysql:host=localhost;dbname=production_db",
            "app_user",
            "SecretPassword123"
        );
        // Kein Fehlermodus gesetzt - PDO wird Fehler offenlegen
    } catch (PDOException $e) {
        // Anfällig: Legt Datenbankfehler mit Anmeldedaten offen
        die("Datenbankfehler: " . $e->getMessage());
    }

    // Anfällig: SQL-Fehlermeldungen offengelegt
    $stmt = $conn->query("SELECT * FROM users WHERE id = $userId");
    return $stmt->fetchAll();
}

// Datei-Einbindung mit offengelegten Pfaden
function loadTemplate($template) {
    // Anfällig: PHP-Interpreter-Fehler legt vollständigen Pfad offen
    include("/var/www/app/templates/" . $template . ".php");
}

// Direkte Include-Anfrage legt Pfade offen
// Angreifer besucht: /app/includes/database.php
// PHP-Fehler: "Failed opening '/var/www/app/includes/database.php'"

// Ungültiges SQL löst detaillierten Fehler aus
// Angreifer sendet: userId = "1 OR 1=1"
// MySQL-Fehler: "You have an error in your SQL syntax near 'OR 1=1'..."

Externe Komponenten (PHP-Interpreter, MySQL-Datenbank) generieren Fehlermeldungen, die Dateipfade, SQL-Syntax und Datenbankdetails enthalten.

Korrigierter Code (PHP)

<?php
// php.ini-Einstellungen (Produktion):
// display_errors = Off
// log_errors = On
// error_log = /var/log/php/errors.log

// Benutzerdefinierter Fehlerhandler für alle externen Fehler
set_error_handler(function($severity, $message, $file, $line) {
    // Detaillierten Fehler intern loggen
    error_log("[$severity] $message in $file in Zeile $line");

    // Ausnahme zur Behandlung werfen
    throw new ErrorException($message, 0, $severity, $file, $line);
});

// Generische Fehleranzeigefunktion
function displayGenericError($errorId) {
    http_response_code(500);
    echo json_encode([
        'error' => 'Ein Fehler ist aufgetreten. Bitte versuchen Sie es erneut.',
        'reference' => $errorId
    ]);
    exit;
}

function getUserData($userId) {
    $errorId = uniqid('err_');

    try {
        $conn = new PDO(
            "mysql:host=localhost;dbname=production_db",
            "app_user",
            getenv('DB_PASSWORD')  // Passwort aus Umgebung
        );

        // Verhindert, dass PDO Fehler offenlegt
        $conn->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $conn->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

        // Parametrisierte Abfrage verhindert SQL-Injection
        $stmt = $conn->prepare("SELECT id, name, email FROM users WHERE id = ?");
        $stmt->execute([$userId]);

        return $stmt->fetchAll(PDO::FETCH_ASSOC);

    } catch (PDOException $e) {
        // Detaillierten Fehler intern loggen
        error_log(
            "[$errorId] Datenbankfehler: " . $e->getMessage() .
            " | Benutzer-ID: " . $userId .
            " | Datei: " . $e->getFile() .
            " | Zeile: " . $e->getLine()
        );

        // Generischer Fehler an Benutzer
        displayGenericError($errorId);
    }
}

function loadTemplate($template) {
    $errorId = uniqid('err_');

    // Template-Namen validieren (Whitelist-Ansatz)
    $allowedTemplates = ['home', 'profile', 'settings', 'about'];

    if (!in_array($template, $allowedTemplates)) {
        error_log("[$errorId] Ungültiges Template angefordert: $template");
        displayGenericError($errorId);
    }

    $templatePath = "/var/www/app/templates/" . $template . ".php";

    if (!file_exists($templatePath)) {
        error_log("[$errorId] Template nicht gefunden: $templatePath");
        displayGenericError($errorId);
    }

    try {
        include($templatePath);
    } catch (Exception $e) {
        error_log("[$errorId] Template-Include-Fehler: " . $e->getMessage());
        displayGenericError($errorId);
    }
}

// Globaler Ausnahmehandler für nicht abgefangene Ausnahmen
set_exception_handler(function($e) {
    $errorId = uniqid('err_');
    error_log("[$errorId] Nicht abgefangene Ausnahme: " . $e->getMessage());
    displayGenericError($errorId);
});

Die Korrektur konfiguriert PHP, um Fehler zu loggen statt anzuzeigen, implementiert globale Fehler- und Ausnahmehandler, verwendet parametrisierte Abfragen und stellt sicher, dass alle externen Komponentenfehler abgefangen werden, bevor sie Benutzer erreichen.


Ausgenutzt in der Praxis

PHP display_errors Aufklärung (Weit verbreitet, Fortlaufend)

Angreifer lösen routinemäßig PHP-Interpreter-Fehler aus, um Aufklärung über Webanwendungen zu sammeln. Durch Anforderung nicht existierender Dateien, Einreichen fehlerhafter Eingaben oder Ausnutzung von Type Juggling lösen Angreifer PHP-Hinweise und -Warnungen aus, die Document-Root-Pfade, eingebundene Dateistandorte und Funktionsnamen enthüllen. Diese Informationen werden verwendet, um Directory-Traversal-Angriffe zu planen, anfällige Datei-Upload-Standorte zu identifizieren und die Anwendungsstruktur zu kartieren.

SQL-fehlerbasierte Injection (Mehrere Organisationen, Fortlaufend)

Fehlerbasierte SQL-Injection-Angriffe lösen absichtlich Datenbankfehler aus, um Daten durch Fehlermeldungen zu extrahieren. Wenn Anwendungen MySQL-, PostgreSQL- oder SQL-Server-Fehlermeldungen offenlegen, erstellen Angreifer Abfragen, die extrahierte Daten in Fehlertexte einbetten. Diese Technik wurde in unzähligen Breaches verwendet, um gesamte Datenbanken durch ausführliche Fehlermeldungen zu exfiltrieren, ohne direkte Abfrageergebnisse zu benötigen.

Django Debug-Modus Informationsoffenlegung (Mehrere Organisationen, 2019)

Sicherheitsforscher entdeckten Tausende von Django-Anwendungen, die mit DEBUG=True in der Produktion liefen, was den externen Fehlerhandler des Frameworks veranlasste, detaillierte Debug-Seiten zu generieren. Diese Seiten legten Umgebungsvariablen, installierte Pakete, Datenbankabfragen und lokale Dateiinhalte offen. Die Offenlegung umfasste API-Schlüssel, Datenbank-Anmeldedaten und Cloud-Provider-Geheimnisse.


Tools zum Testen/Ausnutzen

  • SQLMap — Automatisches SQL-Injection-Tool, das fehlerbasierte Techniken verwendet, um Daten durch Datenbankfehlermeldungen zu extrahieren.

  • Burp Suite Scanner — Automatisierter Scanner, der auf Informationsoffenlegung in Fehlerantworten von externen Komponenten testet.

  • WFuzz — Fuzzing-Tool zum Auslösen von Fehlerbedingungen zur Identifizierung von Informationslecks.


CVE-Beispiele

  • CVE-2004-1581 — Direkte Include-Dateianforderung löste PHP-Interpreter-Fehler aus, der vollständigen Dateipfad offenlegte.

  • CVE-2004-1579 — Ungültige SQL-Abfrage verursachte Datenbankfehlermeldung, die vollständigen Dateipfad enthüllte.

  • CVE-2005-0459 — Direkte Bibliotheksdateianforderung verursachte Pfadoffenlegung durch Interpreter-Fehler.

  • CVE-2005-0433 — Ausführliche externe Fehler legten Klasseninstanziierungsversuche und Dateizugriffsfehler offen.


Referenzen

  1. MITRE Corporation. "CWE-211: Externally-Generated Error Message Containing Sensitive Information." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/211.html

  2. OWASP Foundation. "Error Handling." OWASP Testing Guide. https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/08-Testing_for_Error_Handling/

  3. PHP Documentation. "Error Handling and Logging Configuration." https://www.php.net/manual/en/errorfunc.configuration.php