XSS (Cross-Site Scripting)
Angriffstechnik, bei der Schadcode in Webseiten eingeschleust wird, der im Browser anderer Nutzer ausgeführt wird — etwa um Sessions zu stehlen oder Eingaben mitzulesen.
Cross-Site Scripting (XSS) ist eine Klasse von Sicherheitslücken in Webanwendungen, bei der ein Angreifer schädlichen JavaScript-Code in Seiten einschleust, die von anderen Nutzern aufgerufen werden. Der Browser des Opfers führt den eingeschleusten Code im Kontext der vertrauenswürdigen Webseite aus — mit vollem Zugriff auf Session-Cookies, DOM-Inhalte und Formulareingaben. XSS gehört zu den häufigsten Schwachstellen im Web und ist fester Bestandteil der OWASP Top 10.
XSS-Typen im Vergleich
| Typ | Speicherung | Angriffsvektor | Reichweite |
|---|---|---|---|
| Reflected XSS | Keine (einmalig) | Manipulierter Link mit Schadcode im Parameter | Einzelnes Opfer, das den Link anklickt |
| Stored XSS | Serverseitig in der Datenbank | Schadcode in Kommentaren, Profilen oder Foren | Alle Nutzer, die den Inhalt aufrufen |
| DOM-based XSS | Keine (clientseitig) | Manipulation von DOM-Quellen wie location.hash |
Einzelnes Opfer, rein browserseitig |
Reflected XSS erfordert, dass das Opfer einen präparierten Link anklickt — oft verbreitet über Phishing-Mails oder Social Engineering. Stored XSS ist gefährlicher, da der Schadcode persistent in der Anwendung gespeichert wird und jeden Besucher trifft. DOM-based XSS umgeht serverseitige Schutzmaßnahmen vollständig, weil der Schadcode nie den Server erreicht, sondern ausschließlich im Browser verarbeitet wird.
Auswirkungen eines erfolgreichen Angriffs
Die Konsequenzen von XSS gehen weit über ein Popup-Fenster hinaus. Session Hijacking ermöglicht dem Angreifer, die Session eines eingeloggten Nutzers zu übernehmen, indem Session-Cookies an einen externen Server gesendet werden. Keylogging im Browser fängt Tastatureingaben ab — einschließlich Passwörter und Kreditkartendaten. Über manipulierte Formulare (Phishing im DOM) lassen sich Zugangsdaten abgreifen, ohne dass der Nutzer die vertraute Domain verlässt. In Kombination mit Browser-Exploits kann XSS sogar als Einstiegspunkt für tiefergehende Angriffe dienen.
Schutzmaßnahmen
Die wichtigste Maßnahme ist kontextabhängiges Output Encoding: Jede Ausgabe von Benutzerdaten muss für den jeweiligen Kontext (HTML, JavaScript, URL, CSS) korrekt escaped werden. Moderne Frontend-Frameworks wie React oder Angular übernehmen das standardmäßig — sofern Entwickler nicht explizit unsichere Methoden wie dangerouslySetInnerHTML oder bypassSecurityTrust verwenden. Content Security Policy (CSP) als HTTP-Header schränkt ein, welche Skripte der Browser ausführen darf, und verhindert die Ausführung von Inline-JavaScript. Das HttpOnly-Flag auf Session-Cookies verhindert den Zugriff via JavaScript und entschärft damit Session Hijacking. Input Validation ergänzt diese Maßnahmen, ist aber allein kein ausreichender Schutz.
DOM-based XSS und moderne SPAs
In Single-Page Applications entstehen XSS-Schwachstellen häufig durch unsichere DOM-Manipulation. Quellen (Sources) wie document.location, window.name oder URL-Fragmente fließen in Senken (Sinks) wie innerHTML, eval() oder document.write(). Wir finden in Assessments regelmäßig DOM-XSS in clientseitigen Routing-Logiken und Template-Engines, die bei klassischen serverseitigen Scans unentdeckt bleiben. Statische Analyse-Tools für JavaScript und manuelle Code-Reviews sind hier die effektivsten Erkennungsmethoden.
XSS und SQL-Injection im Vergleich
Beide Schwachstellen basieren auf unzureichender Eingabevalidierung, unterscheiden sich aber im Angriffsziel. SQL-Injection zielt auf den Server und die Datenbank — der Schaden entsteht serverseitig. XSS zielt auf den Browser des Nutzers — der Schadcode wird clientseitig ausgeführt. In der Praxis treten beide häufig gemeinsam auf: Eine Anwendung, die Eingaben nicht korrekt verarbeitet, ist oft für beide Angriffstypen anfällig. Deshalb sollte die Absicherung gegen Injection-Schwachstellen immer ganzheitlich betrachtet werden.
Relevanz für KMUs
Für mittelständische Unternehmen ist XSS besonders relevant, wenn sie Kundenportale, Webshops oder interne Webanwendungen betreiben. Ein erfolgreicher Angriff kann Kundendaten kompromittieren, was neben Reputationsschäden auch DSGVO-Meldepflichten nach sich zieht. Regelmäßige Penetrationstests mit Fokus auf Webanwendungen decken XSS-Schwachstellen systematisch auf. Ergänzend sollte ein restriktiver CSP-Header implementiert und bei jeder Änderung an der Anwendung geprüft werden — ein Schritt, den viele Unternehmen in der Praxis unterschätzen.