Zurück zur Schwachstellen-Datenbank

Einfügung sensibler Informationen in gesendete Daten

Beschreibung

Einfügung sensibler Informationen in gesendete Daten tritt auf, wenn Code Daten an einen anderen Akteur überträgt, aber versehentlich sensible Informationen einschließt, die für den Empfänger nicht zugänglich sein sollten. Dies kann durch unsachgemäße Datenbehandlung, falsche API-Antworten, Debug-Informationen in der Produktion oder das Versäumnis, sensible Felder vor der Übertragung zu entfernen, geschehen. Die sensiblen Informationen können Anmeldedaten, persönliche Daten, interne Systemdetails, Session-Tokens oder andere Daten umfassen, die von der empfangenden Partei missbraucht werden könnten.

Risiko

Diese Schwachstelle kompromittiert direkt die Vertraulichkeit durch Übertragung sensibler Daten an unbeabsichtigte Empfänger. In Webanwendungen können sensible Daten in API-Antworten enthalten sein, die für Endbenutzer oder Dritte zugänglich sind. In vernetzten Systemen können Daten, die für den internen Gebrauch bestimmt sind, über öffentliche Kanäle übertragen werden. Die Auswirkungen reichen von Datenschutzverletzungen (Offenlegung von Benutzerdaten) bis zur vollständigen Systemkompromittierung (Offenlegung von Anmeldedaten oder Tokens). Bei E-Commerce- und Finanzsystemen führt die Offenlegung von Kundentransaktionsdaten zu regulatorischen Verstößen und Betrug. WordPress und andere CMS-Plattformen sind aufgrund komplexer Plugin-Ökosysteme häufig betroffen.

Lösung

Implementieren Sie strikte Ausgabefilterung, die sensible Felder vor der Datenübertragung entfernt. Verwenden Sie Data Transfer Objects (DTOs), die nur die für die Übertragung vorgesehenen Felder enthalten, anstatt interne Objekte direkt zu serialisieren. Wenden Sie das Prinzip der minimalen Rechte auf API-Antworten an – geben Sie nur die minimal notwendigen Daten zurück. Implementieren Sie ordnungsgemäße Zugriffskontrollen, um zu überprüfen, dass Empfänger für alle gesendeten Daten autorisiert sind. Entfernen Sie Debug- und Diagnoseinformationen in der Produktion. Führen Sie Sicherheitsüberprüfungen aller Datenübertragungspunkte durch.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Informationsoffenlegung

Sensible Informationen werden an unbefugte Parteien übertragen, einschließlich Anmeldedaten, persönlicher Daten oder Geschäftsgeheimnisse.
ZugriffskontrolleBereich: Unbefugter Zugriff

Offengelegte Anmeldedaten oder Session-Tokens ermöglichen Angreifern unbefugten Systemzugriff.
ComplianceBereich: Regulierungsverletzung

Übertragung geschützter Daten (PII, PHI, Zahlungsdaten) verletzt DSGVO-, HIPAA-, PCI-DSS-Anforderungen.

Beispielcode + Lösungscode

Anfälliger Code

# ANFÄLLIG: Serialisiert gesamtes Benutzerobjekt
@app.route('/api/user/<id>')
def get_user(id):
    user = User.query.get(id)
    # Sendet ALLE Felder einschließlich Passwort-Hash, interner IDs
    return jsonify(user.__dict__)

# ANFÄLLIG: Enthält Debug-Daten in Antwort
@app.route('/api/order/<id>')
def get_order(id):
    order = Order.query.get(id)
    return {
        "order": order.to_dict(),
        "internal_cost": order.internal_cost,  # Geschäftlich sensibel
        "supplier_id": order.supplier_id,      # Interne Referenz
        "debug_trace": request.environ         # System-Interna
    }

// ANFÄLLIG: Einbettung sensibler Daten in Client-seitigen Code
function loadUserData(userId) {
    const userData = {
        id: userId,
        name: 'Max Mustermann',
        email: '[email protected]',
        apiKey: 'sk_live_abc123xyz',  // Für Client offengelegt!
        internalId: 'INT-12345'       // Interne Referenz offengelegt
    };
    return userData;
}

// ANFÄLLIG: Fehlerantwort mit sensiblen Infos
app.get('/api/resource', (req, res) => {
    try {
        // ... Operation
    } catch (err) {
        res.status(500).json({
            error: err.message,
            connectionString: process.env.DATABASE_URL,  // Anmeldedaten!
            stack: err.stack
        });
    }
});

Korrigierter Code

from dataclasses import dataclass

# SICHER: DTO mit nur öffentlichen Feldern verwenden
@dataclass
class UserDTO:
    id: int
    name: str
    email: str

    @classmethod
    def from_user(cls, user):
        return cls(id=user.id, name=user.name, email=user.email)

@app.route('/api/user/<id>')
def get_user_safe(id):
    user = User.query.get(id)
    if not user:
        return {"error": "Benutzer nicht gefunden"}, 404

    # Nur öffentliche Felder via DTO zurückgeben
    dto = UserDTO.from_user(user)
    return jsonify(asdict(dto))

# SICHER: Explizite Feldauswahl
@app.route('/api/order/<id>')
def get_order_safe(id):
    order = Order.query.get(id)
    if not order:
        return {"error": "Bestellung nicht gefunden"}, 404

    # Nur kundenseitige Daten zurückgeben
    return {
        "order_id": order.public_id,
        "status": order.status,
        "items": [item.to_public_dict() for item in order.items],
        "total": order.total
    }

// SICHER: Öffentliche und private Daten trennen
function loadUserDataSafe(userId) {
    // Nur öffentliche Daten an Client senden
    return {
        id: userId,
        name: 'Max Mustermann',
        displayEmail: 'm***@example.com'  // Maskiert
    };
    // API-Keys und interne IDs bleiben serverseitig
}

// SICHER: Generische Fehlerantworten
app.get('/api/resource', (req, res) => {
    try {
        // ... Operation
    } catch (err) {
        // Detaillierten Fehler intern loggen
        console.error('Resource-Fehler:', err);

        // Generische Nachricht an Client zurückgeben
        res.status(500).json({
            error: 'Bei der Verarbeitung Ihrer Anfrage ist ein Fehler aufgetreten',
            requestId: generateRequestId()  // Nur für Support-Referenz
        });
    }
});

// SICHER: Middleware zum Entfernen sensibler Felder
function sanitizeResponse(data) {
    const sensitiveFields = ['password', 'apiKey', 'internalId', 'ssn', 'creditCard'];
    const sanitized = { ...data };

    sensitiveFields.forEach(field => {
        delete sanitized[field];
    });

    return sanitized;
}

Ausgenutzt in der Praxis

WordPress Core Informationsoffenlegung (WordPress, 2025)

CVE-2025-58246 ermöglicht Angreifern mit Contributor-Level-Privilegien, eingebettete sensible Daten abzurufen, die nicht über WordPres's REST-API offengelegt werden sollten, und betrifft Millionen von WordPress-Installationen.

WooCommerce Wallet-System (WooCommerce, 2025)

CVE-2025-68029 im WP Swings Wallet System für WooCommerce legt sensible Kunden- und Transaktionsdaten durch unsachgemäße Behandlung ausgehender Kommunikation offen.

Windows Speech Service (Microsoft, 2025)

CVE-2025-59509 verursacht, dass der Windows Speech-Dienst versehentlich sensible Informationen in übertragene Daten einschließt, was lokalen Angreifern den Zugriff auf unbefugte Informationen ermöglicht.

Tools zum Testen/Ausnutzen

  • Burp Suite — Abfangen und Analysieren von API-Antworten auf sensible Daten.

  • OWASP ZAP — Automatisiertes Scannen nach Informationen in Antworten.

  • Postman — API-Testing zur Überprüfung von Antwortinhalten.

CVE-Beispiele

Referenzen

  1. MITRE. "CWE-201: Insertion of Sensitive Information Into Sent Data." https://cwe.mitre.org/data/definitions/201.html

  2. OWASP. "API Security Top 10." https://owasp.org/www-project-api-security/