Preisgabe sensibler Informationen an einen unautorisierten Akteur
Beschreibung
Preisgabe sensibler Informationen an einen unautorisierten Akteur tritt auf, wenn ein Produkt absichtlich oder unabsichtlich sensible Informationen an Parteien weitergibt, die keinen Zugang dazu haben sollten. Dies umfasst eine breite Palette von Szenarien, darunter ausführliche Fehlermeldungen, die Systeminterna offenlegen, Debug-Informationen in der Produktionsumgebung, unsachgemäße Zugriffskontrollen auf Datenspeicher, durch Seitenkanale durchgesickerte Informationen sowie sensible Daten in Logs oder Antworten. Die preisgegebenen Informationen können von technischen Details, die weitere Angriffe ermöglichen, bis hin zu personenbezogenen Daten reichen, die Datenschutzverletzungen verursachen.
Risiko
Informationspreisgabe ist eine grundlegende Sicherheitsschwäche, die oft als Vorstufe zu schwerwiegenderen Angriffen dient. Preisgegebene Systemkonfigurationen, Datenbankschemata oder API-Strukturen ermöglichen es Angreifern, gezielte Exploits zu erstellen. Durchgesickerte Zugangsdaten bieten direkten unautorisierten Zugang. Die Preisgabe personenbezogener Daten führt zu Identitätsdiebstahl, Finanzbetrug und Verstoßen gegen regulatorische Vorschriften. Der Equifax-Datenverstoss 2017 legte sensible Daten von 147 Millionen Personen offen, einschließlich Sozialversicherungsnummern. Organisationen erleiden erheblichen Reputationsschäden, rechtliche Haftung und regulatorische Bussgelder (DSGVO, HIPAA, PCI-DSS), wenn sensible Informationen preisgegeben werden.
Lösung
Implementieren Sie das Prinzip der minimalen Rechtevergabe für jeden Datenzugriff. Verwenden Sie generische Fehlermeldungen in der Produktion, die keine internen Details preisgeben. Bereinigen Sie alle Ausgaben, um sensible Informationen vor der Übertragung zu entfernen. Wenden Sie angemessene Zugriffskontrollen auf Datenspeicher, Logs und Konfigurationsdateien an. Implementieren Sie eine Datenklassifizierung und behandeln Sie jede Klasse entsprechend. Entfernen oder deaktivieren Sie Debug-Funktionen in der Produktion. Führen Sie regelmäßige Sicherheitsaudits und Penetrationstests durch. Verwenden Sie automatisierte Tools zur Erkennung von Informationspreisgabe-Schwachstellen. Schulen Sie Entwickler in sicheren Programmierpraktiken für den Umgang mit sensiblen Daten.
Häufige Auswirkungen
| Auswirkung | Details |
|---|---|
| Vertraulichkeit | Bereich: Informationspreisgabe Direkte Preisgabe sensibler Daten einschließlich Zugangsdaten, personenbezogener Informationen, Finanzdaten oder Gesundheitsdaten. |
| Zugriffskontrolle | Bereich: Erweiterung der Angriffsfläche Preisgegebene technische Details über Systemarchitektur, Datenbankschemata oder Softwareversionen ermöglichen gezielte Angriffe. |
| Integrität | Bereich: Folgeangriffe Durchgesickerte Informationen erleichtern SQL Injection, Authentifizierungsumgehung und andere Angriffe, die die Systemintegrität gefährden. |
Beispielcode und Lösung
Verwundbarer Code
# VERWUNDBAR: Detaillierte Fehlermeldung legt Interna offen
def get_user(user_id):
try:
query = f"SELECT * FROM users WHERE id = {user_id}"
result = db.execute(query)
return result
except Exception as e:
# Legt Datenbankstruktur und Abfrage offen
return {"error": f"Database error: {str(e)}, Query: {query}"}
# VERWUNDBAR: Debug-Informationen in der Produktion
@app.route('/api/user/<id>')
def get_user_api(id):
user = User.query.get(id)
return {
"user": user.to_dict(),
"debug": {
"query_time": db.last_query_time,
"db_host": db.host, # Legt Infrastruktur offen
"stack_trace": traceback.format_stack() # Legt Interna offen
}
}
# VERWUNDBAR: Sensible Daten in Logs
def process_payment(card_number, cvv, amount):
logger.info(f"Processing payment: card={card_number}, cvv={cvv}") # PCI-Verstoß!
# ...
// VERWUNDBAR: Stack-Trace in der Antwort
@RestController
public class UserController {
@GetMapping("/user/{id}")
public ResponseEntity<?> getUser(@PathVariable Long id) {
try {
return ResponseEntity.ok(userService.findById(id));
} catch (Exception e) {
// Gibt vollständigen Stack-Trace an den Client weiter
return ResponseEntity.status(500)
.body("Error: " + e.toString() + "\n" + Arrays.toString(e.getStackTrace()));
}
}
}
Sichere Lösung
import logging
# SICHER: Generische Fehlermeldungen
def get_user_safe(user_id):
try:
# Parametrisierte Abfragen verwenden (verhindert auch SQL Injection)
query = "SELECT * FROM users WHERE id = %s"
result = db.execute(query, (user_id,))
return result
except Exception as e:
# Detaillierten Fehler intern protokollieren
logging.error(f"Database error for user {user_id}: {str(e)}")
# Generische Nachricht an den Benutzer zurückgeben
return {"error": "Unable to retrieve user. Please try again later."}
# SICHER: Keine Debug-Informationen in der Produktion
@app.route('/api/user/<id>')
def get_user_api_safe(id):
user = User.query.get(id)
if not user:
return {"error": "User not found"}, 404
# Nur notwendige Daten zurückgeben
return {
"id": user.id,
"name": user.name,
"email": user.email # Nur wenn autorisiert
}
# SICHER: Sensible Daten in Logs maskieren
def process_payment_safe(card_number, cvv, amount):
masked_card = f"****{card_number[-4:]}"
logging.info(f"Processing payment: card={masked_card}, amount={amount}")
# CVV wird niemals protokolliert
# ...
// SICHER: Strukturierte Fehlerbehandlung
@RestController
public class UserController {
private static final Logger logger = LoggerFactory.getLogger(UserController.class);
@GetMapping("/user/{id}")
public ResponseEntity<?> getUser(@PathVariable Long id) {
try {
return ResponseEntity.ok(userService.findById(id));
} catch (UserNotFoundException e) {
return ResponseEntity.status(404)
.body(Map.of("error", "User not found"));
} catch (Exception e) {
// Detaillierten Fehler intern protokollieren
logger.error("Error retrieving user {}: {}", id, e.getMessage(), e);
// Generische Nachricht zurückgeben
return ResponseEntity.status(500)
.body(Map.of("error", "An unexpected error occurred"));
}
}
}
Ausgenutzt in der Praxis
Equifax-Datenverstoss (Equifax, 2017)
Der Equifax-Verstoß legte sensible Daten von 147 Millionen Personen offen, einschließlich Sozialversicherungsnummern, Geburtsdaten und Kreditkartendetails. Die ursprüngliche Schwachstelle (Apache Struts CVE-2017-5638) führte aufgrund unzureichender Datenschutzkontrollen zu umfangreicher Datenpreisgabe.
Facebook Cambridge Analytica (Facebook, 2018)
Unsachgemäße Preisgabe von Benutzerdaten über Facebooks API ermöglichte es Cambridge Analytica, personenbezogene Informationen von 87 Millionen Nutzern zu sammeln, was zu massiven regulatorischen Bussgeldern und Reputationsschäden führte.
Capital One-Datenverstoss (Capital One, 2019)
Fehlkonfigurierte WAF-Regeln legten sensible Informationen offen, darunter 100 Millionen Kreditanträge, Sozialversicherungsnummern und Kontonummern durch einen Server-Side Request Forgery-Angriff.
Tools zum Testen und Ausnutzen
-
Burp Suite -- Antworten abfangen und auf Informationspreisgabe analysieren.
-
OWASP ZAP -- automatisierter Scanner für Informationspreisgabe-Schwachstellen.
-
Nikto -- Webserver-Scanner, der Informationslecks identifiziert.
CVE-Beispiele
-
CVE-2017-5638 -- Apache Struts RCE, der zum Equifax-Verstoß führte.
-
CVE-2024-8884 -- Preisgabe sensibler Informationen in einer Webanwendung.
-
CVE-2023-44487 -- HTTP/2 Rapid Reset Informationspreisgabe.
Referenzen
-
MITRE. "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor." https://cwe.mitre.org/data/definitions/200.html
-
OWASP. "Sensitive Data Exposure." https://owasp.org/www-project-web-security-testing-guide/
-
CWE Top 25. "2024 CWE Top 25 Most Dangerous Software Weaknesses." https://cwe.mitre.org/top25/