Was ist Cross-Site Scripting?
Cross-Site Scripting (XSS) ist eine der häufigsten Schwachstellen in Webanwendungen und gehört seit Jahren zu den OWASP Top 10. Im Kern beschreibt XSS das Einschleusen von bösartigem Code — meist JavaScript — in eine vertrauenswürdige Webseite. Der Angriff richtet sich nicht gegen die Webanwendung selbst, sondern gegen deren Nutzer: Wenn ein Opfer die manipulierte Seite besucht, wird der schädliche Code in seinem Browser ausgeführt.
XSS ist ein clientseitiger Injection-Angriff. Der Angreifer nutzt Schwachstellen in der Eingabeverarbeitung der Webanwendung aus — etwa in Suchfeldern, Kommentarfunktionen, Foren oder URL-Parametern. Überall dort, wo Benutzereingaben ohne ausreichende Bereinigung in den Seiteninhalt eingebettet werden, kann XSS auftreten.
Aus einer hohen Perspektive betrachtet, kann Cross-Site Scripting als das Einbetten von fremdem Code in einen vertrauenswürdigen Kontext zur Ausführung beschrieben werden. Technisch gesehen handelt es sich bei XSS um einen clientseitigen Injection-Angriff, bei dem ein Angreifer versucht, bösartigen Code im Webbrowser des Opfers auszuführen, indem er meist schädliches JavaScript in eine legitime Webseite oder Webanwendung einschleust. Der eigentliche Angriff erfolgt, wenn das Opfer die Ziel-Webanwendung besucht, die den bösartigen Code ausführt. Es ist wichtig zu verstehen, dass die Webanwendung lediglich als Vehikel dient, um den schädlichen Code an den Benutzer zu liefern – die Webanwendung selbst wird nicht angegriffen. Typischerweise suchen Angreifer nach XSS-Schwachstellen in Webanwendungen, die Kommentare, Foren, Nachrichtenboards oder andere Komponenten ermöglichen, bei denen Benutzereingaben in den Seiteninhalt eingebettet werden.
Beim Verifizieren von XSS-Schwachstellen lösen Angreifer üblicherweise Alert-Boxen aus, um die Code-Ausführung im Browser zu demonstrieren. Eine solche Alert-Box nach einem erfolgreichen XSS-Angriff könnte folgendermaßen aussehen:
Diese Alert-Box wurde auf einer Demo-Webanwendung durch Aufruf des folgenden Links erzeugt:
https://x.x.x.x/search.php?keyword=cats<script>alert('XSS demo by e2 Security!')</script>
Wenn dies eine echte, für XSS-Angriffe anfällige Webanwendung wäre, könnte ein Angreifer nun den obigen Link an ein ausgewähltes Opfer senden, in der Hoffnung, dass dieses den Link aufruft. Da die Webanwendung die Benutzereingabe offenbar ohne jegliche Bereinigung oder Kodierung in ihren eigenen Kontext einbettet, wird ein bösartiges JavaScript wahrscheinlich im Browser des Opfers ausgeführt.
Typen: Reflected, Stored und DOM-based XSS
XSS-Schwachstellen werden nach der Art der Payload-Auslieferung in drei Haupttypen unterteilt:
Reflected XSS
Bei Reflected XSS wird der schädliche Code über einen manipulierten Link an die Webanwendung gesendet und direkt in der Serverantwort zurückgespiegelt — ohne gespeichert zu werden. Der Angreifer muss das Opfer dazu bringen, den präparierten Link zu klicken (z. B. per E-Mail oder Phishing).
Beispiel: Ein Suchfeld gibt den Suchbegriff ungefiltert auf der Ergebnisseite aus. Der Angreifer ersetzt den Suchbegriff durch JavaScript-Code, der im Browser des Opfers ausgeführt wird.
Stored XSS
Stored XSS (auch Persistent XSS) ist die gefährlichste Variante. Der schädliche Code wird dauerhaft auf dem Server gespeichert — etwa in einem Datenbankfeld, einem Forumsbeitrag oder einem Benutzerprofil. Jeder Nutzer, der die betroffene Seite aufruft, wird automatisch zum Opfer, ohne einen speziellen Link klicken zu müssen.
DOM-based XSS
Bei DOM-based XSS liegt die Schwachstelle vollständig im Client-seitigen JavaScript-Code. Der Server ist nicht direkt beteiligt — der Angriff manipuliert das Document Object Model (DOM) im Browser des Opfers. Diese Variante ist schwerer zu erkennen, da serverseitige Scanner sie oft übersehen.
Was ist das Risiko?
Wenn eine XSS-Schwachstelle identifiziert wurde, wird ein Angreifer höchstwahrscheinlich versuchen, JavaScript einzuschleusen. Die Möglichkeiten sind vielfältig:
- Session Hijacking: Diebstahl von Session-Cookies, um die Sitzung des Opfers zu übernehmen
- Cross-Site Request Forgery (CSRF): Aktionen im Namen des Benutzers auslösen — Überweisungen, Passwortänderungen, Bestellungen
- Datenexfiltration: Auslesen persönlicher Daten, Tastatureingaben (Keylogger) oder Formularinhalte
- Malware-Verteilung: Weiterleitung auf bösartige Websites oder Drive-by-Downloads
- Defacement: Manipulation des sichtbaren Seiteninhalts, um Nutzer zu täuschen
Das Risiko liegt primär bei den Nutzern der Webanwendung. Für Unternehmen bedeutet eine XSS-Schwachstelle jedoch potenziellen Reputationsschaden, Datenschutzverletzungen (DSGVO) und — wenn Admin-Konten betroffen sind — die Gefahr einer vollständigen Systemkompromittierung.
Wie erkennt und verhindert man XSS?
Die OWASP XSS Prevention Cheat Sheet definiert die wichtigsten Regeln zur Vermeidung von XSS:
- Regel #0: Niemals nicht vertrauenswürdige Daten einfügen, außer an explizit erlaubten Stellen
- Regel #1: HTML-Encoding vor dem Einfügen in HTML-Element-Inhalte
- Regel #2: Attribut-Encoding vor dem Einfügen in HTML-Attribute
- Regel #6: HTML-Markup mit einer dafür konzipierten Bibliothek bereinigen (z. B. DOMPurify)
- HTTPOnly-Flag: Cookies für JavaScript unzugänglich machen
- Content Security Policy (CSP): Inline-Scripts und externe Script-Quellen einschränken
Diese Maßnahmen greifen auf der Ebene von Webserver-Konfiguration und Quellcode. Eine Web Application Firewall (WAF) kann als zusätzliche Schutzschicht dienen, ersetzt aber nicht die korrekte Eingabebereinigung im Code.
Regelmäßige Penetration Tests und automatisierte Security-Scanner (DAST/SAST) helfen, XSS-Schwachstellen proaktiv zu identifizieren, bevor sie ausgenutzt werden.
XSS in der Praxis
XSS ist vergleichsweise einfach zu identifizieren — täglich werden hunderte neue Schwachstellen gemeldet. Zwei Beispiele zeigen die Schwere und Komplexität:
- Chrome XSS Bug (2,5 Jahre zur Behebung): Ein CSP-Bypass in Google Chrome erforderte eine Änderung der HTML-Spezifikation selbst — PortSwigger-Bericht
- Pandora FMS RCE via XSS-Kette: Verkettung mehrerer Schwachstellen (inkl. XSS) zur kritischen Remote Code Execution — PortSwigger-Bericht
- Weglot Reflected XSS (CVE-2023-33999): Unser eigenes Team hat eine Reflected-XSS-Schwachstelle im Weglot-WordPress-Plugin identifiziert und verantwortungsvoll offengelegt — zur Case Study