Zeigen Sie mir, wie Sie gängige Web-Bugs — etwa SQL-Injection und XSS — zu einer Wirkung kombinieren würden, die über einen einzelnen Fund hinausgeht.

Ein guter Web-Pentester denkt in Angriffsketten, nicht in Checklisten. Ein Scanner meldet „Reflected XSS, mittel" und „SQLi, hoch" als zwei Zeilen. Ein Tester zeigt, wie sie zusammen zu „vollständige Admin-Übernahme, kritisch" werden. Diese Geschichte treibt die Behebung an.

Was jeder Bug allein bringt

• SQL-Injection erlaubt Ihnen, Daten zu lesen, zu verändern oder zu löschen, denen die Anwendung vertraut. Je nach Datenbank und Berechtigungen kann sie weiter eskalieren: Passwort-Hashes auslesen, Dateien lesen (LOAD_FILE), eine Web-Shell schreiben oder sogar RCE über Funktionen wie xp_cmdshell (MSSQL) oder gestapelte Abfragen.
• Cross-Site Scripting, insbesondere Stored XSS, führt Angreifer-JavaScript im Browser eines anderen Benutzers aus — wodurch Sie Sitzungstoken stehlen, Aktionen als dieser Benutzer ausführen oder die Seite mitschneiden können.

Die Kette

Betrachten Sie eine Anwendung, in der Kunden-„Notizen" über ein SQL-Backend gespeichert und später in einem Admin-Prüfpanel ohne ordnungsgemäße Ausgabekodierung dargestellt werden:

1. Einschleusen via SQLi oder ein gespeichertes Feld: Sie platzieren eine Stored-XSS-Payload in einen Datensatz — direkt über das Formular oder per SQL-Injection, indem Sie die schädliche Zeichenkette in eine Spalte schreiben, der die Anwendung vertraut und die sie darstellt.
2. Auslösen in einem privilegierten Kontext: Ein Admin öffnet das Prüfpanel; Ihr JavaScript wird in dessen authentifizierter Sitzung ausgeführt.
3. Sitzung stehlen / als Admin handeln: Die Payload exfiltriert das Sitzungscookie des Admins (oder führt, falls HttpOnly, authentifizierte Anfragen in dessen Namen über die eigene API der Anwendung aus), um einen neuen Admin-Benutzer zu erstellen oder Einstellungen zu ändern.
4. Vertiefen via SQLi: Mit Admin-Zugriff kehren Sie zur SQLi zurück, um die gesamte Benutzertabelle auszulesen, Hashes zu knacken und RCE auf dem DB-Host anzustreben — und pivotieren von der Webanwendung zur Infrastruktur.

Jeder Schritt ist bescheiden; die Kette ist eine kritische Kompromittierung.

Warum das im Bericht zählt

Das Aufzeigen der realistischen Kette verschiebt das Risiko von „zwei Web-Bugs" zu „ein Angreifer übernimmt den Admin und die Datenbank" — die Sprache, die dafür sorgt, dass Dinge behoben werden.

Worauf Interviewer achten

Verkettetes Denken, präzise Mechanik für jeden Bug (Stored XSS in privilegiertem Kontext, SQLi-zu-RCE-Pfade) und der Instinkt, die Kette in geschäftliche Auswirkungen zu übersetzen, statt OWASP-Kategorien herunterzubeten.