Information Disclosure

Warum es wichtig ist

Der Server sagt dir ständig mehr, als der Browser zeigt. Ein modernes Frontend empfängt einen vollständigen JSON-Fehler und rendert nur das freundliche Feld message, während es den stack, die Datenbank-Exception und das Debug-Detail stillschweigend verwirft. Lies die rohe Response in einem abfangenden Proxy wie Burp Suite, und dieses verborgene Detail wird zu kostenloser Reconnaissance.

Information Disclosure ist einer der häufigsten Funde im Bug Bounty und der leise erste Schritt in vielen echten Breaches, weil sie Rätselraten in einen gezielten Angriff verwandelt. Sie ist als CWE-200 katalogisiert und untermauert die Reconnaissance-Phase nahezu jedes Web-Assessments.

Häufige Quellen

• Stacktraces: leaken die Sprache, das Framework, die Dateipfade und die Zeilennummern, oft aus einer nicht behandelten Exception.
• Datenbankfehler: leaken die Engine, den Datenbanknamen, die Tabellen und die Spalten, das perfekte Setup für SQL Injection.
• Ausführliche Header: Server- und X-Powered-By-Banner verraten Software und Versionen, die ein Angreifer bekannten CVEs zuordnen kann.
• Over-Fetching-APIs: Endpunkte, die mehr Felder zurückgeben, als die UI anzeigt, manchmal einschließlich der Daten anderer Nutzer oder interner Flags.
• Source Maps, Kommentare und Debug-Endpunkte: legen interne Logik, versteckte Routen und gelegentlich hartkodierte Geheimnisse offen.

Ein durchgespieltes Beispiel

Ein Login-Formular zeigt die generische Meldung "the email or password provided is incorrect". Derselbe Request in einem Proxy gibt einen 401 zurück, dessen JSON außerdem ein stack-Feld trägt, das auf /home/app/node_modules/payload/dist/auth/operations/login.js zeigt. In einem einzigen fehlgeschlagenen Login weiß der Tester nun, dass die Runtime Node.js ist, das Framework Payload und die genauen Server-Pfade, von denen der Browser nichts anzeigte. Dieses Detail leitet jeden folgenden Test.

Wie Angreifer sie nutzen

Ein geleakter Framework-Name weist auf bekannte Schwachstellen hin. Ein geleakter Dateipfad lässt einen Angreifer andere Endpunkte erraten. Ein geleakter Tabellen- und Spaltenname verwandelt einen blinden Injection-Versuch in ein präzises UNION SELECT. Die Offenlegung selbst mag harmlos wirken, doch sie nimmt die Unsicherheit weg, die die meisten Ziele schützt, weshalb Triager sie noch belohnen, selbst wenn keine weitere Ausnutzung gezeigt wird.

Wie du darauf testest

Löse Fehler absichtlich aus und lies die rohe Response. Schick unerwartete Typen, entferne Pflichtfelder, sende fehlerhaftes JSON, frage fehlende Ressourcen an und vergleiche eine 500-Response mit einer normalen 200. Inspiziere jeden Header, halte nach Feldern Ausschau, die die UI nie anzeigt, und prüfe /.well-known/, Source Maps und ausführliche API-Responses. Die Gewohnheit, auf die es ankommt, ist, die Response zu lesen, die der Server tatsächlich gesendet hat, nicht die Seite, die der Browser gezeichnet hat.

Prävention

Zeig Nutzern generische Fehler und halte die Details in serverseitigen Logs. Deaktiviere die Debug-Ausgabe in der Produktion, entferne Versions-Banner und stelle sicher, dass APIs über ausdrückliche Response-Modelle nur autorisierte Felder zurückgeben. Entscheidend: Teste deine eigene Anwendung über einen Proxy, damit du die rohen Responses siehst, die die Browser deiner Nutzer verstecken.