Information Disclosure

Anwendungen verraten regelmäßig mehr, als ihre Entwickler beabsichtigt haben: einen Stack Trace nach einem unerwarteten Fehler, ein vergessenes .git-Verzeichnis neben dem Webroot, eine API, die den kompletten Datensatz zurückgibt, während die Oberfläche drei Felder anzeigt. Einzeln wirkt das unspektakulär, zusammen liefert es einem Angreifer das Wissen für den nächsten Schritt. Im Folgenden lesen Sie, wie Information Disclosure entsteht und wie Sie sie schließen.

Was ist Information Disclosure?

Information Disclosure, auf Deutsch Informationspreisgabe, ist eine Schwachstelle, bei der eine Anwendung technische oder personenbezogene Daten an jemanden herausgibt, der kein Recht darauf hat. Es handelt sich nicht um einen einzelnen Fehler, sondern um eine Kategorie: alles, was ein System unbeabsichtigt über sich selbst oder über seine Benutzer erzählt.

Ein Vergleich aus dem Alltag: ein Geschäft, dessen Lagertür einen Spalt offen steht. Solange niemand hineingeht, verschwindet nichts, aber jeder Vorbeigehende sieht, welcher Tresor dort steht. Der Einbruch folgt später.

In der Praxis stammt das Leck aus einer Handvoll bekannter Ecken:

• Stack Traces und ausführliche Fehlermeldungen mit Framework, Versionsnummer, absolutem Pfad oder einer fehlgeschlagenen Abfrage;
• Debug-Endpunkte, die in der Produktion erreichbar blieben: ein Profiler, eine Statusseite mit der vollständigen Konfiguration, eine Übersicht aller Routen;
• mitausgelieferte Entwicklungsdateien wie ein .git-Verzeichnis, eine .env-Datei oder ein Backup neben dem Webroot;
• Source Maps, die das minifizierte Frontend samt Kommentaren in den Quellcode zurückübersetzen;
• API-Antworten mit mehr Feldern, als die Oberfläche anzeigt, weil das gesamte Modell auf einmal serialisiert wird.

In den OWASP Top 10 fällt das unter A01:2021 Broken Access Control, die passende Klassifizierung ist CWE-200.

Wie funktioniert ein Information-Disclosure-Angriff?

Ein Angreifer beginnt selten mit einem Exploit, sondern mit Aufklärung, und Information Disclosure ist dafür die billigste Quelle. Der häufigste Fall ist zugleich der unauffälligste: ein Portal, das korrekt prüft, wer einen Benutzerdatensatz abrufen darf, und diesen Datensatz dann vollständig zurückgibt.

Verwundbar:

// Das komplette Modell geht über die Leitung
app.get("/api/users/:id", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user);
});

// Und die Fehlerbehandlung schickt den Stack Trace mit
app.use((err, req, res, next) => {
  res.status(500).json({ message: err.message, stack: err.stack });
});

Die Oberfläche zeigt nur Name und Rolle, im Browser wirkt also alles in Ordnung. Die Antwort selbst enthält mehr:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "J. Jansen",
  "email": "j.jansen@example.com",
  "passwordHash": "$2b$12$Q7l0mR4...",
  "totpSecret": "JBSWY3DPEHPK3PXP",
  "role": "admin",
  "internalNote": "Konto an das Inkasso übergeben"
}

Der Angreifer erzwingt hier nichts: Er öffnet die Entwicklerkonsole und liest die Antwort zu seinem eigenen Konto. Das Hash-Feld ermöglicht Offline-Cracking, das TOTP-Geheimnis (Time-based One-time Password, der Code aus der Authenticator-App) entwertet den zweiten Faktor, und die interne Notiz ist ein personenbezogenes Datum.

Die Fehlerbehandlung tut dasselbe mit technischen Angaben. Eine Anfrage mit einem Parameter falschen Typs liefert einen Stack Trace mit dem absoluten Pfad, dem eingesetzten ORM und dessen Version, manchmal samt fehlgeschlagener Abfrage. Genau das macht aus blindem Raten einen gezielten Angriff.

Außerhalb der API wiederholt sich das Muster. Wer per Kopie eines Arbeitsverzeichnisses deployt, stellt die gesamte Versionsgeschichte online. Eine Anfrage verrät es:

curl -s https://app.example.com/.git/HEAD
# ref: refs/heads/main

Kommt diese Zeile statt einer 404 zurück, lässt sich das Repository rekonstruieren, inklusive alter Commits mit einem später aufgeräumten Schlüssel. Source Maps folgen derselben Logik: Eine .map-Datei neben Ihrem Bundle gibt den unbearbeiteten Quellcode zurück.

Die sichere Variante ruht auf zwei Prinzipien: Jede Antwort wird bewusst Feld für Feld zusammengestellt (Response Shaping), und Fehler gehen generisch nach außen, während das Detail im Log bleibt.

Sicher:

// Allowlist der Felder: Was hier fehlt, verlässt den Server nicht
const publicUser = (user) => ({
  id: user.id,
  name: user.name,
  role: user.role
});

app.get("/api/users/:id", async (req, res) => {
  const user = await db.users.findById(req.params.id);
  if (!user) return res.status(404).json({ error: "Nicht gefunden" });
  res.json(publicUser(user));
});

app.use((err, req, res, next) => {
  const ref = crypto.randomUUID();
  logger.error({ ref, err });
  res.status(500).json({ error: "Interner Serverfehler", ref });
});

Der Benutzer erhält eine kurze Meldung mit einer Referenznummer, über die Ihr Support den vollständigen Stack Trace im Log findet. Wichtig ist, dass die Liste positiv formuliert ist: Eine neue Datenbankspalte taucht nicht stillschweigend in der API auf, während eine Liste zu verbergender Felder bei jeder Schemaänderung bricht.

Welche Auswirkungen hat Information Disclosure?

Der Schweregrad schwankt stark, und genau deshalb wird diese Kategorie oft abgetan. Ein X-Powered-By-Header oder eine Versionsnummer auf einer Fehlerseite ist für sich niedrig, denn es gehen keine Daten verloren. Dem Angreifer verrät das trotzdem, welche Exploits einen Versuch wert sind.

In der Mitte stehen die Fälle, die einen weiteren Angriff erst ermöglichen. Ein Stack Trace mit einer fehlgeschlagenen SQL-Abfrage beschleunigt die Ausnutzung einer Injection erheblich, und eine unterschiedliche Meldung für einen unbekannten Benutzer und für ein falsches Passwort verrät, welche E-Mail-Adressen ein Konto haben. Das befeuert gezieltes Phishing und Credential Stuffing.

Am oberen Ende ist die Auswirkung hoch. Eine API, die personenbezogene Daten an Unbefugte herausgibt, ist eine Datenpanne im Sinne der DSGVO, mit Meldepflicht gegenüber der Aufsichtsbehörde und gegebenenfalls gegenüber den Betroffenen. Ein erreichbares .git-Verzeichnis oder eine .env-Datei mit Datenbankpasswörtern ist kein Leck mehr, sondern ein Schlüsselbund. Diese Spanne von niedrig bis hoch macht es nötig, jeden Befund an seinem eigenen Inhalt zu messen.

Wie erkennen Sie Information Disclosure?

Die Suche beginnt damit, Fehler zu provozieren. Schicken Sie einen Buchstaben, wo eine Zahl erwartet wird, oder lassen Sie einen Pflichtparameter weg, und sehen Sie sich an, was zurückkommt. Eine saubere Anwendung antwortet mit einer kurzen Meldung, eine undichte mit einem Stack Trace.

Gehen Sie danach die bekannten Pfade durch: /.git/HEAD, /.env, /server-status, /actuator, /debug und Backups, die nach der Domain benannt sind. Prüfen Sie die Antwort-Header Server und X-Powered-By und durchsuchen Sie das Frontend-Bundle nach Verweisen auf .map-Dateien und nach Kommentaren, die den Build überlebt haben.

Die wertvollsten Befunde liefert allerdings kein Scanner. Legen Sie eine API-Antwort neben die Ansicht, die sie verwendet, und zählen Sie die Felder: Alles, was die Oberfläche nicht anzeigt, ist ein Kandidat. Rufen Sie denselben Endpunkt anschließend als Administrator und als normaler Benutzer auf; identische Antworten bedeuten, dass die API Felder für Administratoren preisgibt. Diese Arbeit setzt Verständnis des Datenmodells voraus, und daran scheitern Scanner. AssistSec prüft diesen Bereich im Rahmen eines Penetrationstests und hält je Befund fest, welches Feld oder welche Datei offen lag.

Wie verhindern Sie Information Disclosure?

• Schalten Sie den Debug-Modus in der Produktion ab und antworten Sie generisch. Eine kurze Meldung mit Referenznummer für den Benutzer, das Detail ausschließlich im Log.
• Stellen Sie jede Antwort ausdrücklich zusammen. Bauen Sie die Ausgabe aus einer festen Feldliste auf, über ein DTO (Data Transfer Object) oder einen Serializer, statt das Datenbankmodell zu serialisieren.
• Halten Sie Entwicklungsdateien aus dem Webroot heraus. Rollen Sie ein Build-Artefakt statt eines Arbeitsverzeichnisses aus und sperren Sie .git und .env zusätzlich im Webserver oder CDN.
• Veröffentlichen Sie keine Source Maps. Laden Sie sie zu Ihrem Error Monitoring hoch, statt sie neben dem Bundle liegen zu lassen.
• Schotten Sie Debug- und Verwaltungsoberflächen ab. Profiler, Metrik- und Health-Endpunkte sowie Adminrouten gehören hinter Authentifizierung oder Netzsegmentierung.
• Begrenzen Sie, was Infrastruktur und Meldungen verraten. Deaktivieren Sie Server-Banner und Directory Listing und verwenden Sie beim Login dieselbe Meldung für vorhandene und nicht vorhandene Konten.
• Behandeln Sie abgeflossene Daten als öffentlich. Rotieren Sie offengelegte Schlüssel und lassen Sie die Korrektur in einem Retest bestätigen.