Sie haben eine SQL-Injection in einer Produktionsanwendung und könnten die gesamte Kundendatenbank exportieren, um die Auswirkung zu beweisen. Was ist der verantwortungsvolle Nachweis?
Kurzantwort
Beweisen Sie die Schwachstelle, ohne dem Kunden zu schaden oder seine Daten anzuhäufen: Zeigen Sie, dass Sie beliebige Daten über die DB-Version, das Schema oder eine einzelne anonymisierte Stichprobe lesen können, und hören Sie dann auf. Den gesamten PII-Datenbestand zu exfiltrieren erzeugt für beide Seiten eine Haftung zur Meldung von Datenpannen und zum Datenumgang. Eine Tabelle zu löschen ist destruktiv und geht weit über einen Proof of Concept hinaus. Die Datenbank zu verschlüsseln und ein Lösegeld zu fordern ist Erpressung, kein Test — eine Straftat, kein Finding.
Das Ziel eines Penetrationstests ist es, ein Risiko aufzuzeigen, damit es behoben wird — nicht, dieses Risiko gegen den Kunden zu verwirklichen. Bei einer SQL-Injection können Sie die Schwachstelle schlüssig beweisen, ohne jemals echte Kundendaten zu berühren.
Warum die minimale Demonstration richtig ist
Extrahieren Sie etwas, das beliebigen Lesezugriff beweist, aber harmlos ist: die Datenbankversion, den aktuellen Benutzer, das Schema, ein COUNT(*) einer sensiblen Tabelle oder einen einzelnen Datensatz mit geschwärzten sensiblen Feldern. Dieser Beweis ist eindeutig — er zeigt, dass Sie Daten lesen können, die Sie nicht lesen dürften — und hinterlässt zugleich keine PII in Ihren Händen und erzeugt keine neue Datenpanne. Das ist Datenminimierung angewandt auf offensive Arbeit, und genau das tut ein reifer Tester.
Warum die anderen Optionen falsch sind
- Die gesamte Kundendatenbank exportieren. In dem Augenblick, in dem Sie echte PII exfiltrieren, haben Sie wohl selbst eine meldepflichtige Datenpanne verursacht, lösen Meldepflichten nach DSGVO/CCPA aus und schaffen für Sie und den Kunden eine Aufbewahrungs- und Löschhaftung. Ein größerer Export beweist den Fehler nicht besser als eine Zeilenzahl.
- Eine Tabelle löschen. Das ist destruktiv und liegt weit außerhalb eines Proof of Concept. Schreibzugriff zu beweisen erfordert niemals, Produktionsdaten zu beschädigen — man kann ihn sicherer demonstrieren (etwa ein harmloser, reversibler Marker in einem nicht kritischen Feld, nur wenn autorisiert).
- Die Datenbank verschlüsseln und Lösegeld fordern. Das ist Ransomware und Erpressung. Es ist schlicht eine Straftat und das Gegenteil der Vertrauensbeziehung, auf der ein Test beruht.
Worauf ein Interviewer achtet
Er will Zurückhaltung und ein Verständnis von Haftung. Ein schwacher Kandidat setzt einen dramatischen Export mit beeindruckender Wirkung gleich. Ein starker weiß, dass der professionellste Beweis der kleinste ist, der die Frage klärt, denn jedes zusätzliche Byte Kundendaten, das Sie berühren, ist ein Risiko, das Sie auf sich und Ihren Kunden importieren.
Wahrscheinliche Anschlussfragen
- Wie beweisen Sie, dass Schreibzugriff besteht, ohne Daten tatsächlich zu ändern oder zu zerstören?
- Welche Datenschutzpflichten greifen in dem Moment, in dem Sie echte PII exfiltrieren?
- Wie würden Sie das Finding für den Bericht sicher belegen?