XSS-Angriffe: Wenn Webinhalte zu Code werden

XSS einfach erklärt

XSS entsteht, wenn eine Webseite fremde Daten als ausführbaren Inhalt interpretiert. Das Skript läuft im Ursprung dieser Seite. Es kann mit ihrem DOM interagieren und oft Anfragen an die Webseite im Namen angemeldeter Personen senden. Die Same-Origin-Regel beschränkt weiterhin den Zugriff auf andere Ursprünge. Ein als HttpOnly markiertes Cookie lässt sich nicht über document.cookie lesen. Das Skript kann innerhalb der angemeldeten Seite trotzdem handeln.

Die Cookie-Einstellung SameSite bestimmt vor allem, wann ein Browser Cookies bei Anfragen über verschiedene Webseiten hinweg mitsendet. Sie hilft bei manchen Angriffen mit gefälschten Anfragen, entfernt aber kein Skript, das bereits auf der eigenen Seite läuft. Die MDN-Referenz zu Set-Cookie erklärt die unterschiedlichen Aufgaben von SameSite und HttpOnly.

Stell dir ein Anschlagbrett vor: Besucher dürfen eine Notiz anheften, aber nicht die Anweisungen oder Bedienelemente des Bretts verändern. Bei XSS wird die Notiz wie ein Teil des Bretts behandelt. Die Grenze bricht dort, wo Daten in einen ausführbaren Zusammenhang eingesetzt werden.

Drei Haupttypen (plus ein paar Sonderfälle)

Die drei Bezeichnungen beschreiben, wo fremde Daten ankommen und ausführbar werden. Die Wege können sich überschneiden: Ein Server kann Daten liefern, die clientseitiger Code später unsicher ins DOM schreibt.

Gespeichertes XSS. Eine Anwendung speichert von Angreifern kontrollierte Inhalte, etwa in einem Kommentar, Profil oder Supportticket, und zeigt sie anderen Personen an. Wie viele betroffen sind, hängt davon ab, wer diese Inhalte sehen kann und wie die Anwendung sie darstellt.

Reflektiertes XSS. Ein Server übernimmt Eingaben aus einer Anfrage, oft einen URL-Parameter, in seine Antwort, ohne sie für die Ausgabestelle sicher zu codieren. Ein präparierter Link kann jemanden zu dieser Antwort führen.

DOM-basiertes XSS. Clientseitiger Code liest fremde Daten und übergibt sie an eine unsichere DOM-Funktion wie innerHTML. Die Daten können aus einer URL, Serverantwort oder anderen Quelle stammen. Entscheidend ist die unsichere Verarbeitung im Browser. Der OWASP-Leitfaden zu DOM-basiertem XSS beschreibt die Gegenmassnahmen.

Self-XSS ist etwas anderes: Angreifer überreden jemanden, Code selbst auszuführen, etwa durch Einfügen in die Entwicklerwerkzeuge. XS-Leaks erschliessen Informationen über andere Ursprünge anhand beobachtbarer Nebenwirkungen und bilden ebenfalls eine eigene Problemklasse. Der Kern von XSS bleibt, dass fremde Daten in einer vertrauten Seite zu aktivem Inhalt werden.

So läuft ein XSS-Angriff Schritt für Schritt

Ein typischer Ablauf zeigt, wo Schutzmassnahmen der Anwendung die Kette unterbrechen können.

1. 1

   Einen Einstiegspunkt finden

   Angreifer suchen einen Kommentar, URL-Parameter, eine Nachricht oder einen anderen Wert, der später auf einer Webseite erscheint.
2. 2

   Eine unsichere Ausgabestelle erreichen

   Die Anwendung setzt diesen Wert so ein, dass der Browser ihn als HTML oder Skript statt als Text interpretieren könnte.
3. 3

   Code zur Zielperson bringen

   Angreifer bewegen jemanden dazu, die betroffene Seite aufzurufen, etwa über einen präparierten Link oder geteilte Inhalte.
4. 4

   Auf der betroffenen Seite ausführen

   Führt der Browser den Code aus, teilt er den Ursprung der Seite und kann mit dort verfügbaren Inhalten und Schnittstellen interagieren, soweit Browser und Webseite es zulassen.
5. 5

   Verfügbare Rechte missbrauchen

   Je nach Anwendung kann der Code die Seite verändern, zugängliche Daten lesen oder Anfragen über die aktuelle Session senden. Die Schutzmassnahmen der Webseite bestimmen, was tatsächlich gelingt.

Was eingeschleuster Code tun kann

XSS kann mehr bewirken als eine sichtbare Veränderung der Seite. Entscheidend sind die Daten und Funktionen, die auf der betroffenen Seite zugänglich sind. Diese vier Beispiele zeigen mögliche Folgen, nicht deren Häufigkeit.

Handlungen im Konto. Eingeschleuster Code kann Anfragen von einer angemeldeten Seite aus senden und möglicherweise Tokens lesen, die die Anwendung JavaScript zugänglich macht. HttpOnly verhindert das direkte Lesen entsprechender Cookies, aber nicht automatisch Handlungen innerhalb desselben Ursprungs. Die MDN-Dokumentation zu Cookies erläutert diese Grenze.

Zugangsdaten abfangen. Ein verändertes Formular könnte ein Passwort oder andere Daten erfassen, während jemand sie eingibt. Die betroffene Person muss diese Informationen auf der Seite eingeben. XSS legt kein andernorts gespeichertes Passwort automatisch offen.

Seiteninhalte verändern. Code kann Links, Anweisungen oder angezeigte Transaktionsdetails austauschen. Er kann im Rahmen der geltenden Regeln auch weitere Webinhalte laden. Für die Ausführung lokaler Malware wäre zusätzlich ein Browserangriff oder ein vom Nutzer bestätigter Download nötig.

Daten preisgeben. Ein Skript kann Angaben lesen, die bereits auf der Seite stehen, und sie senden, wenn Netzwerkregeln das erlauben. Die Same-Origin-Regel begrenzt weiterhin das Lesen fremder Webseiten. Ein Risiko bleiben die sensiblen Daten und Berechtigungen der betroffenen Seite selbst.

Fünf illustrative Szenarien

Diese hypothetischen Beispiele sind keine Berichte über tatsächliche Vorfälle. Sie zeigen, an welchen Übergängen von Daten zu Code ein Team genauer hinsehen sollte.

Community-Webseite. Eine Kommentarvorschau stellt eingereichtes HTML als aktiven Inhalt dar. Öffnet eine angemeldete Moderationsperson die Vorschau, könnte der eingeschleuste Code innerhalb der Moderationsoberfläche handeln. Die Lösung liegt in einer sicheren Darstellung und der Prüfung dieses besonders berechtigten Ablaufs.

Onlineshop. Ein Suchbegriff wird ohne passende Codierung in eine HTML-Antwort übernommen. Wer einem präparierten Link folgt, könnte einen veränderten Link zur Kasse sehen. Die echte Domain allein beweist dann nicht, dass der angezeigte Link sicher ist.

Patientenportal. Eine gespeicherte Nachricht erscheint im Browser einer medizinischen Fachperson. Auch bei HttpOnly-Cookies könnte eingeschleuster Code möglicherweise Angaben lesen, die auf der Seite stehen, oder Anfragen senden, für die die Fachperson berechtigt ist. Zugriffsregeln und sichere Darstellung sind beide wichtig.

Finanzübersicht. Clientseitiger Code liest ein URL-Fragment und schreibt es mit innerHTML in die Seite. Ein schädlicher Link könnte die Anzeige für Kundinnen und Kunden verändern. Serverseitige Prüfungen und Bestätigungen könnten eine unberechtigte Überweisung dennoch verhindern. Der DOM-Fehler muss trotzdem behoben werden.

Öffentliche Informationsseite. Eine alte CMS-Vorlage behandelt ein Titelfeld als vertrauenswürdiges HTML. Eine Person mit Bearbeitungsrechten oder einem kompromittierten Konto könnte öffentliche Hinweise verändern. Alte Vorlagen und die Rechte für ihre Inhalte verdienen dieselbe Prüfung wie neue Komponenten.

Warum XSS weiter vorkommt

Moderne Frameworks codieren viele Werte standardmässig sicher. Roher HTML-Code, unsichere DOM-Funktionen, Abkürzungen in Vorlagen und fremde Skripte können diesen Schutz aber umgehen. OWASP behandelt XSS als Risiko für Webanwendungen. Sein Leitfaden zur XSS-Prävention erklärt, warum keine einzelne Massnahme alle Ausgabekontexte abdeckt.

Grosse Anwendungen verbinden alte Vorlagen, moderne Komponenten, nutzergenerierte formatierte Texte und Skripte anderer Anbieter. Welche Korrektur nötig ist, hängt davon ab, wo Daten herkommen und wo sie landen: HTML-Text, Attribute, URLs, Skriptblöcke und DOM-Funktionen verlangen unterschiedliche Behandlung. Automatische Werkzeuge helfen, doch wer nur Serverantworten prüft, kann clientseitige Verarbeitung übersehen. Ergänze Browsertests und Codeprüfung für alle Wege, die fremde Daten verarbeiten.

Praktische Schritte für Nutzer

Nutzer können eine verwundbare Webseite nicht selbst reparieren, aber begrenzen, was sie ihr preisgeben. Diese Schritte verringern manche Risiken, ohne Schutz vor XSS zu garantieren.

Prüfe die Adresse einer Webseite, bevor du Zugangsdaten eingibst oder wichtige Handlungen bestätigst. Halte deinen Browser aktuell und entferne unnötige Erweiterungen. Nutze getrennte Konten oder Browserprofile, wenn Aufgaben unterschiedliche Vertrauensstufen haben. Vermutest du einen Angriff, melde dich ab und prüfe die Kontoaktivität von einem vertrauenswürdigen Gerät aus. Ob eine Abmeldung andere Sessions beendet, hängt vom Dienst ab. Browser.lol kann Seitencode in einem entfernten Browser ausführen; XSS kann dort aber weiterhin die Konto-Session und deine Eingaben oder Bestätigungen beeinflussen. Auch Anzeige, Zwischenablage und Downloads verbinden die Session mit deinem Gerät.

Checkliste für Entwicklung und Sicherheit

Die Vermeidung von XSS beginnt in der Anwendung. Diese fünf Massnahmen solltest du in den Kontexten testen, die deine Anwendung tatsächlich verwendet.

Ausgaben passend zum Kontext codieren. HTML-Text, Attribute, URLs, JavaScript und CSS brauchen unterschiedliche Behandlung. Verwende für reinen Text Textfunktionen und für benötigtes formatiertes HTML ein gepflegtes Bereinigungswerkzeug.

Framework-Standards bewusst nutzen. React, Vue und Angular können dargestellte Werte sicher codieren. Funktionen für rohes HTML und direkte DOM-Schreibvorgänge umgehen Teile dieses Schutzes. Prüfe solche Ausnahmen besonders genau.

Eine restriktive CSP einrichten. Eine gut durchdachte Content Security Policy mit Nonces oder Hashes kann die Ausführung von Skripten nach einer Einschleusung begrenzen. Sie ist ein zusätzlicher Schutz, kein Ersatz für sichere Codierung und Bereinigung. Siehe den OWASP-Leitfaden zu CSP.

Datenwege und unsichere DOM-Funktionen prüfen. Statische Analyse kann riskante Muster wie ungeprüfte Zuweisungen an innerHTML markieren. Ergänze Tests für dargestellte Seiten und clientseitige Datenwege.

Besonders berechtigte Abläufe überprüfen. Teste, wo Mitarbeitende fremde Inhalte ansehen, formatierter Text erlaubt ist und Seiten sensible Handlungen auslösen können. Tests im entfernten Browser können das lokale Risiko durch Seitencode verringern, machen einen Angriffsnachweis aber nicht harmlos. Nutze Testkonten und keine echten Geheimnisse.

Fremde Daten von ausführbarem Code trennen

XSS ist ein Fehler an der Grenze zwischen Daten und ausführbarem Inhalt. Kontextabhängige Codierung, sichere DOM-Funktionen, sorgfältig behandeltes formatiertes HTML und eine restriktive CSP verringern die Wahrscheinlichkeit, dass fremde Daten zu Code werden. Cookie-Einstellungen und serverseitige Prüfungen können manche Folgen begrenzen. Keine einzelne Massnahme beseitigt XSS vollständig.

Ein entfernter Browser ändert, wo Seitencode läuft. Er repariert die verwundbare Webseite nicht und schützt ein Konto nicht vor Handlungen innerhalb der entfernten Session. Trenne sensible Konten, prüfe wichtige Handlungen und behebe den unsicheren Datenweg an seiner Quelle. Diese Massnahmen ergänzen einander, weil sie unterschiedliche Teile des Risikos abdecken.