XSS-Angriffe verstehen und verhindern: Schutz vor Cross-Site Scripting

XSS-Angriff bezeichnet eine Sicherheitslücke in Webanwendungen, bei der Angreifer erreichen, dass ihr eigener JavaScript-Code im Browser eines anderen Nutzers ausgeführt wird. Dabei kann der Server der Website selbst weiterhin einwandfrei funktionieren: Das Problem entsteht, weil die Anwendung Benutzereingaben fehlerhaft verarbeitet und der Browser diese als Teil der Seite oder als auszuführenden Code interpretiert.

Durch XSS lassen sich Inhalte auf der Website verändern, gefälschte Formulare anzeigen, Aktionen im Namen des Nutzers durchführen und auf Informationen zugreifen, die auf der Seite verfügbar sind. Die Gefahr besteht darin, dass der Schadcode im Kontext der echten Website läuft und damit dieselben Rechte wie legitime JavaScript-Skripte dieser Seite hat.

Was ist ein XSS-Angriff und warum spricht man von Cross-Site Scripting?

Cross Site Scripting, oder Cross-Site Scripting (XSS), entsteht, wenn eine Website nicht vertrauenswürdige Benutzerdaten ohne ausreichende Prüfung oder sichere Verarbeitung in eine HTML-Seite einbaut. Dadurch kann ein eigentlich harmloser Text vom Browser als HTML oder JavaScript interpretiert werden.

Ein einfaches Beispiel ist eine Kommentarfunktion. Gibt ein Nutzer eine Nachricht ein, speichert der Server diese und zeigt sie anderen Besuchern an. Wird der eingegebene Text ungeprüft ins HTML übernommen, kann ein Angreifer eine Konstruktion einschleusen, die den Browser dazu bringt, JavaScript auszuführen statt gewöhnlichen Text anzuzeigen.

Vereinfacht gesagt, vermischt XSS Daten mit Befehlen. Nutzer sollten nur Informationen wie Namen, Kommentare oder Suchanfragen an die Seite senden können. Doch durch einen Entwicklungsfehler behandelt der Browser Teile dieser Daten als Anweisungen, die ausgeführt werden.

Der Begriff Cross Site Scripting ist historisch gewachsen und etwas irreführend. Für einen XSS-Angriff muss kein Skript tatsächlich von einer anderen Seite stammen. Das Wesentliche ist, dass nicht vertrauenswürdiger Code im Kontext einer vertrauenswürdigen Seite ausgeführt wird.

Wie unterscheidet sich XSS von klassischen Website-Hacks?

Beim klassischen Hacken versucht ein Angreifer, Zugriff auf den Server, die Datenbank, das Admin-Panel oder das Dateisystem zu bekommen. XSS hingegen zielt auf den Browser des Besuchers ab.

Der Angreifer muss also nicht die vollständige Kontrolle über den Server erlangen. Es reicht, eine Stelle zu finden, an der die Website externe Daten unsicher in die Seite einbaut. Öffnet das Opfer diese Seite, wird der Schadcode im Browser - also auf dem Endgerät des Nutzers - ausgeführt.

Deshalb unterscheidet sich XSS beispielsweise von einer SQL-Injection. Bei einer SQL-Injection gelangen falsch verarbeitete Daten in eine Datenbankabfrage, während bei XSS potenziell ausführbarer Code im Browser landet. Mehr zur serverseitigen Perspektive solcher Schwachstellen erfahren Sie hier. Beide Angriffsarten hängen mit unsicherer Verarbeitung von Fremddaten zusammen, betreffen aber unterschiedliche Bereiche einer Webanwendung.

Wie funktioniert ein XSS-Angriff - und wie gelangt JavaScript auf die Seite?

Ein XSS-Angriff beginnt, wenn eine Webanwendung Daten aus einer nicht vertrauenswürdigen Quelle erhält - etwa Kommentare, Suchanfragen, URL-Parameter, Benutzernamen oder andere vom Nutzer änderbare Informationen. Werden diese Daten ohne sichere Verarbeitung in die Seite integriert, kann der Browser sie als HTML oder JavaScript ausführen.

Der entscheidende Fehler geschieht beim Aufbau der Seite. Der Server oder clientseitiges JavaScript fügt den übergebenen Wert genau dort ein, wo der Browser Markup oder Code erwartet. So können präparierte Daten die Struktur des Dokuments verändern und unerwünschte Befehle auslösen.

Der Browser kann dabei nicht unterscheiden, ob ein Code-Fragment vom Entwickler oder einem Angreifer stammt. Ist JavaScript erst einmal auf der Seite und nicht durch Schutzmechanismen blockiert, wird es im Kontext der aktuellen Website ausgeführt.

Vom Nutzereingabefeld bis zur Ausführung des Skripts

Typisch startet die Kette mit einem Formularfeld oder einem URL-Parameter. Der Nutzer sendet Daten an die Seite, die Anwendung übernimmt sie und gibt sie im HTML zurück. Bei korrekter Verarbeitung werden Sonderzeichen so umgewandelt, dass der Browser sie als Text anzeigt.

Fehlt dieses sogenannte Escaping, kann der Inhalt die HTML-Struktur manipulieren. Dann interpretiert der Browser die Seite mit den eingeschleusten Elementen und Event-Handlern. Das Problem liegt daher nicht einfach im Vorhandensein von Nutzereingaben, sondern darin, in welchem Kontext und wie diese ausgegeben werden.

Manchmal ist nicht einmal eine Speicherung auf dem Server nötig. Oft reicht es, wenn ein Wert aus der Adresszeile oder einem anderen Browser-Objekt unsicher in den DOM eingefügt wird. Deshalb tritt XSS sowohl bei klassischen serverseitigen Seiten als auch bei modernen JavaScript-lastigen Web-Apps auf.

Was kann bösartiges JavaScript tun?

Die Möglichkeiten von XSS hängen von der Website und den Browsereinstellungen ab. Ein Schadskript kann lesbare Inhalte der Seite auslesen, Oberflächenelemente verändern, Nutzeraktionen beobachten und Anfragen im Namen des aktiven Tabs senden.

So kann ein Angreifer etwa einen Teil der Oberfläche durch ein gefälschtes Login-Formular ersetzen. Da dies im Kontext der echten Seite geschieht, bemerkt der Nutzer möglicherweise nicht, dass er mit einer Manipulation interagiert.

Außerdem kann JavaScript Aktionen mit den Rechten der aktuellen Seite ausführen. Ist der Nutzer bereits angemeldet, sendet der Browser oft automatisch Session-Daten bei Anfragen an die Seite. XSS kann daher nicht nur Informationen auslesen, sondern auch im Namen des Opfers Aktionen auslösen.

XSS und Session-Diebstahl

Eines der bekanntesten XSS-Szenarien ist der Diebstahl von Session-Cookies. Nach dem Login erhält der Browser meist eine Sitzungs-ID, die ein erneutes Passwort-Eingeben erspart.

Ist ein solches Cookie per JavaScript auslesbar, kann eine erfolgreiche XSS-Attacke den Wert abgreifen und an den Angreifer senden. Mit diesem Identifier lässt sich unter Umständen die Identität des Nutzers übernehmen, ohne das Passwort zu kennen.

Moderne Websites reduzieren dieses Risiko mit dem HttpOnly-Attribut, das JavaScript den Zugriff auf Cookies verbietet. Damit bleibt XSS aber nicht folgenlos: Schadcode kann dennoch mit der Seite interagieren und erlaubte Aktionen im Browser anstoßen. Der Schutz der Session muss also immer mit der Beseitigung der Schwachstelle kombiniert werden.

Arten von XSS-Angriffen: Stored, Reflected und DOM XSS

XSS-Angriffe unterscheiden sich danach, wie und wann der bösartige Code in die Seite gelangt. Die Haupttypen sind Stored XSS, Reflected XSS und DOM XSS. Für Nutzer sehen die Folgen gleich aus - fremder JavaScript-Code läuft im Browser -, doch Ursache und Einschleusungsweg sind verschieden.

Stored XSS (Persistentes XSS)

Bei Stored XSS werden Schad-Daten auf der Website gespeichert und später automatisch anderen Nutzern angezeigt. Die Quelle können Kommentare, Nachrichten, Profilbeschreibungen, Foreneinträge oder andere Felder sein, deren Inhalt in der Datenbank landet.

Die Gefahr: Der Angreifer muss dem Opfer nicht jedes Mal einen speziellen Link schicken. Ein einziges Mal das schädliche Fragment an einer verwundbaren Stelle zu platzieren, reicht - ab dann wird es allen Besuchern der betroffenen Seite ausgeliefert.

Daher gilt Stored XSS oft als besonders kritisch. Ist eine anfällige Seite viel besucht, kann schon ein gespeichertes Skript viele Nutzer betreffen.

Reflected XSS

Reflected XSS funktioniert anders: Die schädlichen Daten werden nicht gespeichert, sondern gelangen per Anfrage in die Seite und werden sofort zurückgegeben.

Beispielsweise zeigt eine Website eine Suchanfrage direkt in der Überschrift der Ergebnisse an oder gibt einen URL-Parameter in einer Fehlermeldung aus. Wird der Wert ohne Escape übernommen, kann eine speziell präparierte URL JavaScript ausführen.

Für diese Attacke muss ein Nutzer meist dazu gebracht werden, einen vorbereiteten Link zu öffnen oder bestimmte Daten zu senden. Reflected XSS wird daher oft mit Social Engineering, Phishing-Mails oder getarnten Links kombiniert.

DOM XSS

DOM XSS entsteht direkt im Browser und bezieht sich auf die clientseitige Verarbeitung von Daten durch JavaScript. Der Server liefert dabei eine an sich sichere Seite aus, die Schwachstelle tritt aber erst nach dem Laden auf.

Beispielsweise liest ein Skript einen Wert aus der URL, dem Hash (#), einem Parameter oder einer anderen Quelle aus und fügt ihn unsicher in die Seite ein. Wird der Wert als HTML geparst, kann der Angreifer den DOM manipulieren und eigenen Code einschleusen.

Das Hauptmerkmal: Das Problem liegt in der clientseitigen Logik. Die schädliche Zeichenkette muss nicht einmal an den Server geschickt werden, wodurch reines Logfile-Monitoring die Schwachstelle schwerer erkennt.

Zusammengefasst: Stored XSS setzt auf gespeicherte Daten, Reflected XSS nutzt die sofortige Rückgabe von Eingaben, und DOM XSS basiert auf unsicherer Verarbeitung im Browser selbst. Die Ursache ist immer gleich: Die Anwendung erlaubt es, dass nicht vertrauenswürdige Daten in einen Kontext gelangen, den der Browser als Code interpretiert.

Wie gefährlich ist XSS für Nutzer und Website-Betreiber?

Die Gefahr von XSS liegt darin, dass Schadcode im Kontext einer echten, vom Nutzer vertrauten Website ausgeführt wird. Die Seite sieht dabei äußerlich normal aus, doch der Browser führt Aktionen aus, die von den Entwicklern nie vorgesehen waren.

Die Folgen hängen von der jeweiligen Anwendung ab. Auf einer Seite bleibt es bei Oberflächenmanipulationen, auf einer anderen können Anfragen im Namen angemeldeter Nutzer ausgelöst oder sensible Daten ausgelesen werden.

Datenklau und Aktionen im Namen des Nutzers

Bösartiges JavaScript kann Informationen von der Seite auslesen, Interaktionen mit Bedienelementen verfolgen und Daten an externe Server senden. Besonders gefährdet sind persönliche Konten, interne Dienste und Admin-Panels, auf denen vertrauliche Daten verfügbar sind.

Ist ein Nutzer bereits angemeldet, betrachtet der Browser die Seite weiterhin als vertrauenswürdig und sendet oft automatisch Session-Daten mit. So kann ein Skript Aktionen im Namen des Opfers initiieren, selbst wenn die Session-ID nicht direkt auslesbar ist.

Manipulation der Benutzeroberfläche

Mit XSS lässt sich der DOM der Seite verändern. Ein Angreifer kann neue Elemente hinzufügen oder bestehende ersetzen, etwa ein gefälschtes Login-Popup, eine erneute Passwortabfrage oder eine umgeleitete Schaltfläche.

Die Gefahr ist hier besonders groß, weil alles auf der echten Domain passiert. Der Nutzer sieht die gewohnte Adresse und erkennt möglicherweise nicht, dass Teile der Oberfläche von einem eingeschleusten Skript stammen.

Über XSS können auch Links manipuliert, Warnungen versteckt, Seiteninhalte ausgetauscht oder Nutzer auf andere Websites umgeleitet werden. Teilweise dient XSS als Zwischenschritt für Phishing-Angriffe.

Warum XSS auch bei HTTPS gefährlich bleibt

HTTPS schützt nicht vor XSS. Zwar verschlüsselt HTTPS die Verbindung zwischen Browser und Server und verhindert Manipulationen des Datenverkehrs auf dem Transportweg, es prüft aber nicht, ob JavaScript innerhalb der Seite sicher ist.

Hat der Server einer legitimen Website bereits eine Seite mit eingeschleustem Skript ausgeliefert - oder erzeugt der Client-Code einen verwundbaren DOM -, erhält der Browser alle Inhalte sicher verschlüsselt, führt sie aber trotzdem aus.

Das ist der grundlegende Unterschied zwischen XSS und Traffic-Manipulation: Beim Man-in-the-Middle-Angriff versucht ein Dritter, den Datenstrom zwischen den Teilnehmern zu verändern, während bei XSS der Schadcode direkt innerhalb der vertrauenswürdigen Seite ausgeführt wird. Hier erfahren Sie mehr über den Ablauf von MITM-Angriffen und Schutzmaßnahmen.

Wie schützt man eine Website vor XSS?

Der zentrale Grundsatz gegen Cross-Site Scripting lautet: Daten aus Nutzer- oder externen Quellen dürfen niemals automatisch als sicher gelten. Die Anwendung muss kontrollieren, wohin Daten gelangen und wie der Browser sie interpretiert.

Eine einzige Prüfung reicht oft nicht aus. Effektiver Schutz kombiniert korrektes Escaping der Ausgabe, sichere DOM-Manipulation, Einschränkungen für Skriptausführung und zusätzliche Absicherung der Sitzungen.

Ausgabe escapen

Die wichtigste Maßnahme gegen XSS: Benutzereingaben sollten grundsätzlich als Text und nicht als HTML-Code ausgegeben werden. Gibt ein Nutzer einen Kommentar, Namen oder eine Suchanfrage ein, muss der Browser Sonderzeichen als Text behandeln, nicht als Markup.

Die Art des Escapings hängt vom Kontext ab. Daten in HTML, Attributen, URLs oder JavaScript erfordern jeweils andere Verarbeitung. Fehler entstehen, wenn überall dieselbe Methode genutzt oder ganz auf Escape verzichtet wird.

Moderne Templates und Webframeworks escapen die Ausgabe meist automatisch. Der Schutz entfällt aber, wenn Entwickler das automatische Escaping abschalten oder Roh-HTML einfügen.

Validierung und Bereinigung von Daten

Eine Validierung begrenzt das erlaubte Format der Eingaben. So sollte ein Altersfeld kein HTML, ein Dateiname keine Steuerzeichen akzeptieren.

Muss eine Anwendung tatsächlich HTML zulassen - etwa im Editor oder bei formatierten Kommentaren -, reicht das Verbot von Sonderzeichen nicht. Hier wird das Eingabefeld bereinigt: Nur bestimmte, sichere Tags und Attribute sind erlaubt, potenziell gefährliche Elemente werden entfernt.

Doch auch die Filterung der Eingabe ersetzt nicht das sichere Escaping beim Ausgeben. Selbst geprüfte Daten können später in einen anderen Kontext geraten. Die Schutzmaßnahmen müssen daher direkt dort greifen, wo die Information in die Seite eingefügt wird.

Content Security Policy und sicherer Umgang mit dem DOM

Eine Content Security Policy (CSP) ist eine zusätzliche Sicherheitsebene. Damit lässt sich festlegen, von wo der Browser JavaScript laden und ausführen darf, und das Ausführen nicht autorisierter Skripte einschränken.

Eine sauber konfigurierte CSP kann die Folgen von XSS deutlich abmildern, ersetzt aber nicht das Schließen der eigentlichen Schwachstelle. Werden weiterhin unsichere Nutzerdaten in die Seite eingebaut, bleibt das Problem bestehen.

Besonderes Augenmerk gilt clientseitigem JavaScript. Für die Textausgabe sollte textContent statt Methoden, die Zeichenketten als HTML interpretieren, genutzt werden. innerHTML ist nur dann sicher, wenn die Entwickler die Inhalte exakt kontrollieren oder zuvor bereinigen.

Schutz von Cookies und Sitzungen

Selbst wenn XSS nicht völlig ausgeschlossen werden kann, lässt sich der potenzielle Schaden begrenzen. Für Session-Cookies empfiehlt sich das HttpOnly-Attribut, das JavaScript den Zugriff verbietet.

Das Secure-Attribut beschränkt die Übertragung auf HTTPS-Verbindungen, SameSite kontrolliert das Senden von Cookies bei Anfragen von anderen Seiten. Diese Mechanismen beseitigen XSS nicht, erschweren aber den Diebstahl oder Missbrauch der Session.

In der Praxis ist effektive XSS-Abwehr immer mehrschichtig: Escaping vor der Ausgabe, Bereinigung potenziell gefährlichen HTMLs, sichere DOM-Manipulation, CSP zur Einschränkung von Skripten und zusätzlicher Cookie-Schutz auf Browser-Ebene.

Fazit

Ein XSS-Angriff entsteht, wenn eine Website es erlaubt, dass nicht vertrauenswürdige Daten als auszuführender Code im Browser des Nutzers landen. Schad-JavaScript kann über gespeicherte Daten, URL-Parameter oder unsichere DOM-Verarbeitung eingeschleust werden. Stored XSS, Reflected XSS und DOM XSS erfordern bei der Suche nach Schwachstellen jeweils unterschiedliche Ansätze.

Der beste Schutz: Benutzerdaten nie ungeprüft mit HTML oder JavaScript mischen. Escaping der Ausgabe, Bereinigung erlaubter HTML-Tags, vorsichtiger Umgang mit dem DOM, eine Content Security Policy und geschützte Cookies sollten gemeinsam eingesetzt werden. Je früher eine Webanwendung Daten und Code strikt trennt, desto unwahrscheinlicher wird es, dass ein gewöhnliches Eingabefeld zum Einfallstor für XSS wird.