Anatomie eines Findings: von der Fehlermeldung zum Datenleck

Anonymisiert und verfremdet. Keine echten Kundendaten, keine identifizierbaren Systeme — nur der Mechanismus, weil der lehrreich ist.

Es begann mit einer Kleinigkeit: einer Fehlermeldung, die zu viel verriet.

Schritt 1: Die geschwätzige Fehlerseite

Ein Tippfehler in einem Suchfeld, und die Anwendung antwortete nicht mit „Ups, etwas ist schiefgelaufen“, sondern mit einem vollständigen Stacktrace — inklusive Framework-Version, Dateipfad und einem Fragment der SQL-Abfrage.

PDOException: SQLSTATE[42S22]
in /var/www/app/src/Db/Query.php:212
SELECT * FROM products WHERE name LIKE '%...%'

Allein das ist „nur“ ein Low-Finding. Aber es war die Landkarte.

Schritt 2: Der Parameter, der zu viel vertraut

Das LIKE '%...%' verriet: Die Eingabe landet ungefiltert in der Query. Ein Test-String bestätigte die Injection — die Anwendung verarbeitete eingeschleuste SQL-Syntax, statt sie als Text zu behandeln.

GET /search?q=test' UNION SELECT username,pw_hash,NULL FROM users-- -

Schritt 3: Aus „kann sein“ wird „ist“

Die Antwort enthielt plötzlich Benutzernamen und Passwort-Hashes. Kein Login nötig, kein Social Engineering — eine einzige manipulierte URL. Aus der harmlosen Fehlermeldung war ein meldepflichtiger Datenabfluss nach DSGVO geworden.

Was den Unterschied gemacht hätte

• Parametrisierte Queries. Eine Zeile pro Abfrage — und die ganze Kette bricht.
• Generische Fehlerseiten. Ohne die Landkarte aus Schritt 1 wird Recon teuer.
• Least Privilege in der DB. Der App-User hätte nie die users-Tabelle lesen dürfen.

Die Lehre

Schwachstellen sind selten ein einzelner Fehler. Sie sind eine Kette kleiner Nachlässigkeiten, von denen jede für sich harmlos wirkt. Ein guter Report bewertet deshalb nicht nur das einzelne Finding, sondern die Kette — und priorisiert nach dem realen Weg, den ein Angreifer geht.

Genau diesen Aufbau siehst du im Sample-Report.