Definition

Cross-Site Scripting (XSS) bezeichnet Angriffe, bei denen Angreifer über eine Webanwendung eingeschleusten Schadcode in Form bösartiger Skripte in harmlosen, vertrauenswürdigen Websites platzieren, sodass er im Browser eines anderen Endnutzers ausgeführt wird.

Auf einen Blick

Typen: Reflected, Stored und DOM-based XSS wurden lange als drei getrennte Typen betrachtet, überschneiden sich aber in Wirklichkeit.

Einordnung: In der aktuellen Ausgabe der OWASP Top 10 gehört XSS zur Kategorie A05 Injection.

Schutz: Ausgabedaten müssen nach CON.10 kodiert werden; das Attribut HttpOnly am Session-Cookie dämmt laut MITRE nur Angriffe auf dieses Cookie ein.

Was ist Cross-Site Scripting?

Cross-Site-Scripting-Angriffe gelingen nach OWASP dort, wo eine Webanwendung Eingaben eines Nutzers in der von ihr erzeugten Ausgabe verwendet, ohne sie zu validieren oder zu kodieren. Weil der Browser das Skript für vertrauenswürdig hält, kann es auf Cookies, Session-Tokens und weitere sensible Informationen zugreifen, die der Browser für diese Website speichert und verwendet. Besonders schwer wiegen Angriffe, bei denen das Session-Cookie des Nutzers offengelegt wird, weil ein Angreifer dann die Sitzung kapern und das Konto übernehmen kann. Laut MITRE ist die häufigste mit Cross-Site Scripting ausgeführte Attacke die Offenlegung privater, in Cookies gespeicherter Informationen wie Sitzungsinformationen.

Enthält das Kundenportal eines Versicherers eine XSS-Lücke, kann eingeschleuster Code im Browser eines angemeldeten Kunden Daten auf der Seite auslesen oder Aktionen mit dessen Berechtigungen auslösen. Der Eintrag CWE-79 beschreibt die Schwachstelle so, dass ein Produkt vom Nutzer steuerbare Eingaben nicht oder fehlerhaft neutralisiert, bevor sie in eine Ausgabe gelangen, die als Webseite an andere Nutzer ausgeliefert wird.

Wie funktioniert Cross-Site Scripting?

Ein Angreifer nutzt eine Webanwendung, um bösartigen Code, im Allgemeinen ein Skript auf der Browserseite, an einen anderen Endnutzer zu senden. Laut OWASP besteht der häufigste Weg darin, den schädlichen Inhalt als Parameter in eine URL einzubauen, die öffentlich gepostet oder direkt per E-Mail an Opfer gesendet wird. Bei serverseitigem Reflected und Stored XSS unterscheiden sich die Abläufe darin, wie die Nutzlast beim Server ankommt; bei DOM-based XSS liegt die Quelle der Daten dagegen im DOM statt beim Server. Bei Reflected XSS veranlasst der Angreifer das Opfer, gefährliche Inhalte an eine verwundbare Webanwendung zu übermitteln; die Anwendung spiegelt diese Inhalte an das Opfer zurück, und der Webbrowser führt die Inhalte aus.

Bei serverseitigem Stored XSS speichert die Anwendung gefährliche Daten in einer Datenbank, einem Nachrichtenforum, einem Besucherprotokoll oder einem anderen vertrauenswürdigen Datenspeicher. Bei DOM-based XSS schleust eine clientseitige Anwendung den Schadcode in die Seite ein, indem die Anwendung das DOM manipuliert. Die HTTP-Antwort ändert sich dabei nicht; der clientseitige Code in der Seite wird jedoch wegen der bösartigen Änderungen in der DOM-Umgebung anders ausgeführt.

Cross-Site Scripting im Vergleich

Kriterium Reflected XSS Stored XSS DOM-based XSS CSRF
Kennzeichen Die Eingabe wird sofort von der Webanwendung zurückgegeben, etwa in einer Fehlermeldung oder einem Suchergebnis, ohne dauerhaft gespeichert zu werden Bei serverseitigen Varianten wird die Eingabe auf dem Zielserver gespeichert, etwa in einer Datenbank, einem Forum, einem Besucherprotokoll oder einem Kommentarfeld DOM-basiertes XSS entsteht, wenn clientseitiger Code nicht vertrauenswürdige Daten so verarbeitet, dass sie im Browser als Code ausgeführt werden können. Zwingt einen Endnutzer zu ungewollten Aktionen in einer Webanwendung, in der er gerade authentifiziert ist
Beziehung zu den anderen Typen Steht in der OWASP-Matrix auf derselben Achse wie Stored XSS; kann zugleich DOM-based sein Steht in der OWASP-Matrix auf derselben Achse wie Reflected XSS; kann zugleich DOM-based sein Teilmenge von Client XSS: Die Datenquelle liegt im DOM statt beim Server; kann zugleich Stored oder Reflected sein Eigener Angriff; das BSI führt die Verhinderung von Cross-Site-Request-Forgery als eigene Anforderung CON.10.A15 (S)
Erreicht die Nutzlast den Server? Bei Server XSS ja, als Teil der Anfrage; der Server gibt die Eingabe in seiner Antwort zurück. Bei DOM-based Varianten muss die Eingabe den Server nicht erreichen, etwa wenn sie im Fragment hinter dem Zeichen # steht Bei Server XSS ja, die Eingabe liegt danach auf dem Server. Bei clientseitig gespeicherten Varianten muss die Eingabe den Server nicht erreichen. Bei einem URL-Parameter ja, als Teil der HTTP-Anfrage, sodass sich der Angriff serverseitig erkennen ließe; der Teil nach dem Zeichen # wird vom Browser nicht an den Server gesendet Nicht Gegenstand der verwendeten Quellen

Woran erkenne ich Cross-Site Scripting?

Merkmal Worauf es ankommt
Ungeprüfte Eingaben in der Ausgabe Ausgabedaten können Schadcode enthalten, der auf dem Zielsystem interpretiert oder ausgeführt wird; ein Beispiel ist JavaScript-Code, der in Formulardaten eingegeben wird.
Reine Informationsseiten Eine „read-only“- oder „brochureware“-Seite ist nach OWASP nicht davor gefeit, von schwerwiegenden Reflected-XSS-Angriffen betroffen zu sein.
Einordnung in Risikolisten In der aktuellen Ausgabe der OWASP Top 10 gehört Cross-Site Scripting zur Kategorie A05 Injection; die Kategorie führt es im Vergleich zu SQL Injection als Schwachstelle mit hoher Häufigkeit und geringer Auswirkung und mit mehr als 30.000 CVEs, SQL Injection dagegen mit geringer Häufigkeit und hoher Auswirkung.

Schutz im Ernstfall

Vorbeugen

  • Der Baustein CON.10 des IT-Grundschutz-Kompendiums (Edition 2023) sieht vor, dass Ausgabedaten so kodiert werden müssen, dass schadhafter Code auf dem Zielsystem nicht interpretiert oder ausgeführt wird.
  • Nach CON.10 sollten mindestens die HTTP-Header Content-Security-Policy, Strict-Transport-Security, Content-Type, X-Content-Type-Options sowie Cache-Control verwendet werden.
  • Zur Eindämmung von XSS-Angriffen auf das Session-Cookie des Nutzers sollte das Cookie mit dem Attribut HttpOnly gesetzt werden.

Beispiele aus der Praxis

  • Ein Angreifer speichert ein bösartiges Skript in einem Kommentarfeld eines Forums; lädt ein Besucher den Kommentar, kann das Skript dessen Session-Cookie auslesen und an den Angreifer senden.
  • Ein Angreifer verschickt per E-Mail einen Link, dessen URL-Parameter ein Skript enthält; ruft ein Nutzer ihn auf und übernimmt eine verwundbare Anwendung den Parameter in ihre Antwort, wird das Skript im Browser des Nutzers ausgeführt.
  • Enthält das Kundenportal eines Versicherers eine XSS-Lücke, könnte eingeschleuster Code im Browser eines angemeldeten Kunden Daten auf der Seite auslesen.