Offenlegung sensibler Informationen aufgrund inkompatibler Richtlinien

Beschreibung

Offenlegung sensibler Informationen aufgrund inkompatibler Richtlinien ist eine Schwachstelle, die auftritt, wenn die beabsichtigte Funktionalität eines Produkts Informationen gemäß der Sicherheitsrichtlinie des Entwicklers offenlegt, diese Informationen aber gemäß den Sicherheitsrichtlinien anderer Stakeholder als sensibel gelten. Das grundlegende Problem entsteht durch eine Diskrepanz zwischen dem, was Entwickler für akzeptabel halten offenzulegen, und dem, was Benutzer, Administratoren oder regulatorische Rahmenwerke als sensibel betrachten. Diese Trennung manifestiert sich oft, wenn Anwendungen persönliche Daten wie Sozialversicherungsnummern anzeigen, Systemkonfigurationen durch Debugging-Funktionen offenlegen oder interne Identifikatoren enthüllen, bei denen verschiedene Stakeholder unterschiedliche Erwartungen an den Schutz haben. Die Schwäche unterstreicht die Wichtigkeit, mehrere Perspektiven zu berücksichtigen, wenn bestimmt wird, was sensible Informationen darstellt.

Risiko

Inkompatible Sicherheitsrichtlinien erzeugen erhebliche Risiken, weil sensible Informationen offengelegt werden können, selbst wenn Entwickler glauben, ordnungsgemäße Sicherheitspraktiken zu befolgen. Offenlegung persönlicher Daten kann zu Identitätsdiebstahl, Datenschutzverletzungen und regulatorischer Non-Compliance mit Gesetzen wie DSGVO, HIPAA oder CCPA führen. Offenlegung technischer Informationen durch Funktionen wie phpinfo() kann Softwareversionen, Konfigurationseinstellungen und Serverpfade enthüllen, die Angreifern bei der Planung gezielter Angriffe helfen. Geschäftssensible Informationen wie interne Benutzerkennungen, Preisalgorithmen oder Kundendaten können versehentlich mit Benutzern geteilt werden, die sie dann weiter offenlegen. Das Risiko wird verstärkt, weil die Offenlegung beabsichtigt ist statt versehentlich, was sie systematisch macht und potenziell alle Benutzer des Systems betrifft.

Lösung

Etablieren Sie ein umfassendes Datenklassifizierungsframework, das alle Stakeholder-Perspektiven berücksichtigt, einschließlich Benutzer, Administratoren, Regulierungsbehörden und Geschäftspartner. Führen Sie Datenschutz-Folgenabschätzungen durch, um Informationen zu identifizieren, die jeder Stakeholder als sensibel betrachten könnte. Implementieren Sie das Prinzip der minimalen Offenlegung – legen Sie nur Informationen offen, die für die Funktionalität streng notwendig sind. Erstellen Sie Konfigurationsoptionen, die es Administratoren ermöglichen zu kontrollieren, welche Informationen basierend auf den Richtlinien ihrer Organisation angezeigt werden. Entfernen oder deaktivieren Sie Entwicklungsfunktionen wie phpinfo() und Debug-Endpunkte in Produktionsumgebungen. Überprüfen Sie Anwendungsausgaben regelmäßig mit Vertretern verschiedener Stakeholder-Gruppen. Implementieren Sie Datenmaskierung für sensible Felder und stellen Sie Audit-Trails bereit, wenn auf sensible Informationen zugegriffen wird.

Häufige Auswirkungen

Auswirkung	Details
Vertraulichkeit	Bereich: Vertraulichkeit Sensible Informationen werden von unbefugten Parteien gelesen, die gemäß ihren Sicherheitsrichtlinien keinen Zugang haben sollten. Dies kann persönliche Daten, Systemkonfigurationen oder geschäftssensible Informationen umfassen, die verschiedene Stakeholder als geschützt erwarten.

Beispielcode

Anfälliger Code (Java/JSP)

Der folgende Code demonstriert die Offenlegung von Informationen, die Benutzer als sensibel betrachten würden, auch wenn Entwickler dies möglicherweise nicht tun:

// Anfällige JSP-Seite - legt sensible Benutzerdaten offen ohne Benutzererwartungen zu berücksichtigen
<%@ page import="com.example.UserService" %>
<%
    UserService userService = new UserService();
    User user = userService.getCurrentUser();
%>

<!-- Anfällig: Entwickler denkt dies ist "Benutzerprofil" aber legt sensible Daten offen -->
<html>
<head><title>Benutzerprofil</title></head>
<body>
    <h1>Willkommen, <%= user.getFullName() %></h1>

    <!-- Benutzer erwarten, dass diese privat sind -->
    <div class="profile-details">
        <p>SVN: <%= user.getSocialSecurityNumber() %></p>
        <p>Geburtsdatum: <%= user.getDateOfBirth() %></p>
        <p>Wohnadresse: <%= user.getHomeAddress() %></p>
        <p>Telefon: <%= user.getPhoneNumber() %></p>
    </div>

    <!-- Kreditkarte gezeigt um "Benutzern zu helfen sich zu erinnern" -->
    <div class="payment-info">
        <p>Kartennummer: <%= user.getCreditCardNumber() %></p>
        <p>Ablauf: <%= user.getCardExpiry() %></p>
    </div>

    <!-- Entwickler-Debug-Infos in Produktion belassen -->
    <div class="debug" style="display:none">
        <!-- Benutzer und Admins würden nicht erwarten, dass dies offengelegt wird -->
        <p>Benutzer-ID: <%= user.getInternalId() %></p>
        <p>Kontotyp: <%= user.getAccountType() %></p>
        <p>Kreditwürdigkeit: <%= user.getCreditScore() %></p>
    </div>
</body>
</html>

// Anfällig: phpinfo()-Äquivalent in Java-Servlet
@WebServlet("/status")
public class StatusServlet extends HttpServlet {

    // Entwickler hält dies für "hilfreich" für Support
    // Aber legt sensible Systemkonfiguration offen
    protected void doGet(HttpServletRequest request, HttpServletResponse response) {
        PrintWriter out = response.getWriter();
        out.println("<h1>Systemstatus</h1>");

        // Legt alle Systemeigenschaften offen - sensibel für Admins
        out.println("<h2>Systemeigenschaften</h2>");
        for (Object key : System.getProperties().keySet()) {
            out.println(key + "=" + System.getProperty((String)key) + "<br>");
        }

        // Legt Umgebungsvariablen einschließlich Geheimnisse offen
        out.println("<h2>Umgebungsvariablen</h2>");
        for (Map.Entry<String, String> entry : System.getenv().entrySet()) {
            out.println(entry.getKey() + "=" + entry.getValue() + "<br>");
        }
    }
}

Korrigierter Code (Java/JSP)

// Korrigierte JSP-Seite - respektiert Datenschutzerwartungen der Benutzer
<%@ page import="com.example.UserService" %>
<%@ page import="com.example.PrivacySettings" %>
<%
    UserService userService = new UserService();
    User user = userService.getCurrentUser();
    PrivacySettings privacy = user.getPrivacySettings();
%>

<html>
<head><title>Benutzerprofil</title></head>
<body>
    <h1>Willkommen, <%= user.getDisplayName() %></h1>

    <div class="profile-details">
        <!-- Korrigiert: Nur maskierte Versionen zeigen, mit Benutzerkontrolle -->
        <% if (privacy.showSsnLastFour()) { %>
            <p>SVN: XXX-XX-<%= user.getSsnLastFour() %></p>
        <% } else { %>
            <p>SVN: [Verborgen - klicken zum Anzeigen]</p>
        <% } %>

        <!-- Korrigiert: Nur zeigen was Benutzer explizit erlaubt hat -->
        <% if (privacy.showDateOfBirth()) { %>
            <p>Geburtsdatum: <%= user.getFormattedDob() %></p>
        <% } %>

        <!-- Korrigiert: Niemals vollständige Kreditkarte zeigen -->
        <p>Karte: **** **** **** <%= user.getCardLastFour() %></p>
    </div>

    <!-- Korrigiert: Keine Debug-Infos in Produktion -->
</body>
</html>

// Korrigiert: Eingeschränkter Status-Endpunkt mit ordnungsgemäßer Zugriffskontrolle
@WebServlet("/admin/status")
public class SecureStatusServlet extends HttpServlet {

    private static final Set<String> SAFE_PROPERTIES = Set.of(
        "java.version", "java.vendor", "os.name", "os.arch"
    );

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {

        // Korrigiert: Admin-Authentifizierung erforderlich
        if (!isAdmin(request)) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN);
            return;
        }

        PrintWriter out = response.getWriter();
        out.println("<h1>Systemstatus</h1>");

        // Korrigiert: Nur sichere, nicht-sensible Eigenschaften offenlegen
        out.println("<h2>Systeminformation</h2>");
        for (String key : SAFE_PROPERTIES) {
            out.println(key + "=" + System.getProperty(key) + "<br>");
        }

        // Korrigiert: Niemals Umgebungsvariablen offenlegen
        out.println("<p>Anwendungsversion: " + getAppVersion() + "</p>");
        out.println("<p>Status: Gesund</p>");

        // Zugriff für Audit loggen
        auditLogger.log("Statusseite aufgerufen von: " + getAdminUsername(request));
    }

    private boolean isAdmin(HttpServletRequest request) {
        // Admin-Authentifizierung und -Autorisierung verifizieren
        return request.isUserInRole("ADMIN");
    }
}

Die Korrektur respektiert Datenschutzerwartungen der Benutzer durch Maskierung sensibler Daten, Bereitstellung von Benutzerkontrolle über Sichtbarkeit, Entfernung von Debug-Informationen und Beschränkung von Systeminformations-Endpunkten auf autorisierte Administratoren.

Ausgenutzt in der Praxis

phpinfo()-Offenlegungsvorfälle (Mehrere Organisationen, Fortlaufend)

Die phpinfo()-Funktion war eine anhaltende Quelle von Informationsoffenlegung in PHP-Anwendungen. Sicherheitsforscher entdecken regelmäßig öffentlich zugängliche phpinfo-Seiten, die Datenbank-Anmeldedaten in Umgebungsvariablen, interne Netzwerktopologie, Dateisystempfade und installierte Modulversionen enthüllen. Angreifer nutzen diese Informationen für gezielte Ausnutzung. Große Schwachstellendatenbanken enthalten Hunderte von CVEs im Zusammenhang mit phpinfo()-Offenlegung.

https://www.php.net/manual/en/function.phpinfo.php

Sozialversicherungsnummer-Offenlegung in öffentlichen Aufzeichnungen (Verschiedene Regierungsseiten, 2000er-2010er)

Mehrere Regierungswebsites legten Sozialversicherungsnummern von Bürgern durch öffentliche Aufzeichnungssuchen, Wählerregistrierungsdatenbanken und Gerichtsdokumentensysteme offen. Während Entwickler dies unter ihrer Interpretation der Gesetze über öffentliche Aufzeichnungen als akzeptabel betrachteten, sahen Bürger und Datenschutzvertreter Sozialversicherungsnummern als sensibel an. Diese Vorfälle führten zu Gesetzesänderungen und strengeren Datenschutzanforderungen.

https://www.epic.org/privacy/ssn/

Telnet-Umgebungsvariablen-Leck (Mehrere Hersteller, 2005)

CVE-2005-1205 und CVE-2005-0488 dokumentierten Schwachstellen, bei denen Telnet-Clients sensible Umgebungsvariablen (USER, HOME, PWD) an bösartige Telnet-Server sendeten. Während Entwickler Umgebungsvariablen als akzeptabel zum Teilen betrachteten, erwarteten Benutzer, dass diese Informationen lokal bleiben. Die Schwachstelle wurde ausgenutzt, um Aufklärung über verbindende Benutzer zu sammeln.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1205

Tools zum Testen/Ausnutzen

Burp Suite — Web-Sicherheitstest-Plattform zur Identifizierung offengelegter sensibler Informationen in Anwendungsantworten.
Nuclei — Schwachstellen-Scanner mit Vorlagen zur Erkennung von phpinfo() und anderen Informationsoffenlegungs-Endpunkten.
Google Dorks — Suchtechniken zum Finden offengelegter phpinfo-Seiten und sensibler Daten auf öffentlichen Websites.

CVE-Beispiele

CVE-2002-1725 — Skript, das phpinfo() aufruft, legte Systemkonfigurationsdetails an unbefugte Benutzer offen.
CVE-2005-1205 — Telnet-Client ermöglichte Servern, sensible Umgebungsvariablen von Clients zu erhalten.
CVE-2003-1038 — Produkt listete DLLs und vollständige Dateipfadnamen auf und legte Systemstruktur offen.

Referenzen

MITRE Corporation. "CWE-213: Exposure of Sensitive Information Due to Incompatible Policies." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/213.html
OWASP Foundation. "Information Exposure." OWASP. https://owasp.org/www-community/vulnerabilities/Information_exposure
NIST. "Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)." Special Publication 800-122. https://csrc.nist.gov/publications/detail/sp/800-122/final