Was ist Cross-Site Scripting?

Cross-Site Scripting, kurz XSS, entsteht, wenn eine Webanwendung nicht vertrauenswürdige Daten ohne passende kontextabhängige Kodierung in eine Seite einsetzt. Der Browser interpretiert diese Daten anschließend als aktives HTML oder JavaScript. Der Code läuft mit Origin und Berechtigungen der betroffenen Website.

Reflected XSS gibt den Payload in der unmittelbaren Antwort zurück, Stored XSS speichert ihn für spätere Besucher und DOM-basiertes XSS entsteht durch unsicheren clientseitigen Code. Angreifer manipulieren Seiteninhalte, führen Aktionen im Namen des Opfers aus oder lesen Daten, die JavaScript zugänglich sind. HttpOnly-Cookies reduzieren eine Folge, verhindern XSS aber nicht.

Wie lässt sich XSS verhindern?

• - Automatische, kontextabhängige Ausgabekodierung nutzen und ungefilterte HTML-Ausgabe vermeiden.
• - HTML mit einer erprobten Positivliste bereinigen, wenn Rich Text wirklich benötigt wird.
• - Gefährliche Browser-APIs wie `innerHTML` nicht mit nicht vertrauenswürdigen Inhalten verwenden.
• - Eine restriktive Content Security Policy als zusätzliche Schicht einsetzen, nicht als primäre Fehlerbehebung.

Codebeispiele: serverseitiges und DOM-basiertes XSS

Verwundbares Blade-Template:

<!-- Gibt fremdes HTML ungefiltert aus -->
{!! $comment !!}

Sichere Textausgabe:

<!-- Blade kodiert HTML-Sonderzeichen kontextgerecht -->
{{ $comment }}

DOM-basiert – verwundbar und sicher:

// Verwundbar: der Browser interpretiert den Wert als HTML
output.innerHTML = new URLSearchParams(location.search).get('name');

// Sicher, wenn nur Text benötigt wird
output.textContent = new URLSearchParams(location.search).get('name');

Für erlaubten Rich Text genügt textContent nicht; dort muss eine gepflegte HTML-Sanitizer-Bibliothek mit enger Positivliste eingesetzt werden. URL-, Attribut- und JavaScript-Kontexte brauchen jeweils eigene Regeln.

Warum ist der Ausgabekontext wichtig?

HTML-Text, Attribute, URLs, CSS und JavaScript-Strings folgen unterschiedlichen Parserregeln. Eine Kodierung, die in einem Kontext sicher ist, kann in einem anderen unsicher sein. Am robustesten bleiben nicht vertrauenswürdige Daten vollständig außerhalb ausführbarer Kontexte.

Reflected, Stored und DOM-basiert

Reflected XSS entsteht, wenn eine Eingabe aus dem aktuellen Request ungeeignet in die Antwort übernommen wird. Stored XSS speichert die Nutzlast etwa in einem Profil, Kommentar oder Ticket und liefert sie später an weitere Benutzer aus. DOM-basiertes XSS entsteht vollständig im Browser, wenn JavaScript nicht vertrauenswürdige Daten an einen gefährlichen DOM-Sink wie innerHTML übergibt. Die Varianten können sich überschneiden; entscheidend ist der Weg der Daten von ihrer Quelle bis zum ausführbaren Kontext.

Was kann ein XSS-Angriff bewirken?

Der Code läuft im Sicherheitskontext der betroffenen Website. Er kann sichtbare Inhalte verändern, Aktionen im Namen des angemeldeten Benutzers auslösen, Formulare manipulieren oder lesbare Daten an einen externen Server senden. Ein HttpOnly-Cookie lässt sich nicht direkt per JavaScript auslesen, verhindert aber keine Requests mit der bestehenden Sitzung. Besonders kritisch ist Stored XSS in Ansichten für Support- oder Administrationspersonal.

Wie wird XSS getestet?

Ein Test verfolgt Eingaben durch Server-Templates und clientseitigen Code bis zur Ausgabe. Dabei werden HTML-Text, Attribute, URLs, JavaScript, CSS und DOM-Sinks getrennt betrachtet. Ein einfacher Suchstring zeigt zunächst nur eine Reflexion; ein kontrollierter, kontextspezifischer Nachweis bestätigt die Ausführbarkeit. Code-Review und Browser-Instrumentierung finden Datenflüsse, die ein Scanner wegen komplexer Interaktionen oder später Verarbeitung übersieht.

Welche Rolle spielen CSP und Cookies?

Eine strenge Content Security Policy kann viele Nutzlasten blockieren und macht Ausnutzung schwieriger. Sie ist eine zweite Verteidigungslinie, keine Alternative zu korrektem Encoding und sicheren DOM-APIs. HttpOnly, SameSite und Secure begrenzen einzelne Folgen. Gemeinsam reduzieren diese Kontrollen den Schaden, während die eigentliche XSS-Ursache im Ausgabepfad behoben werden muss.