Cross-Site-Scripting (XSS)
Cross-Site-Scripting ist eine Angriffsart, bei der Angreifer fremden Skript-Code in eine Website einschleusen, der dann im Browser der Besucher ausgeführt wird – etwa um Sitzungen zu übernehmen oder Eingaben mitzulesen.
Cross-Site-Scripting zählt zu den häufigsten Angriffsklassen auf Websites; die Content-Security-Policy ist die wirksamste Browser-seitige Gegenmaßnahme.
In einfachen Worten
Bei Cross-Site-Scripting nutzt ein Angreifer aus, dass eine Website Eingaben ungeprüft wieder ausgibt. Schleust er an einer solchen Stelle Skript-Code ein, führt der Browser eines arglosen Besuchers diesen Code im Vertrauens-Kontext der Seite aus – mit Zugriff auf Sitzungs-Daten, Eingabefelder und gespeicherte Anmelde-Informationen. Man unterscheidet drei Varianten: reflektiertes XSS (der Code steckt in einem manipulierten Link und wird sofort zurückgespiegelt), persistentes XSS (der Code wird dauerhaft gespeichert, etwa in einem Kommentar, und trifft jeden Besucher) und DOM-basiertes XSS (der Code entsteht erst durch unsicheres Verarbeiten im Browser selbst). Wirksam abgewehrt wird XSS durch zwei sich ergänzende Maßnahmen: das konsequente Maskieren aller Ausgaben auf Server-Seite und eine Content-Security-Policy, die das Ausführen nicht freigegebener Skripte im Browser unterbindet.
Wozu brauche ich das?
Relevant für jede Website mit Eingabe-Möglichkeiten – Kontakt-Formulare, Such-Felder, Kommentar-Funktionen, Anmelde-Bereiche. Überall dort, wo Nutzer-Eingaben verarbeitet und später wieder angezeigt werden, ist Cross-Site-Scripting die naheliegende Angriffsfläche. Sicherheits-Prüfungen für Anwendungen behandeln es als eine der ersten zu testenden Schwachstellen. Verwandte Angriffe wie Clickjacking betreffen dieselben Interaktions-Punkte einer Seite.
Beispiel aus der Praxis
Ein Such-Feld gibt den eingegebenen Begriff auf der Ergebnis-Seite ungeprüft wieder aus. Ein Angreifer baut einen Link, in dem statt eines Suchbegriffs Skript-Code steht, und verschickt ihn. Klickt ein angemeldeter Nutzer darauf, läuft der Code in seinem Browser und liest die Sitzungs-Kennung aus – der Angreifer kann die Sitzung übernehmen. Mit sauberer Ausgabe-Maskierung wäre der Code als harmloser Text dargestellt worden; eine Content-Security-Policy hätte seine Ausführung zusätzlich verhindert. Eine Auslieferung über HTTPS sichert dabei nur den Transport, nicht aber gegen eingeschleusten Code.
Wirtschaftlicher Nutzen
Ein erfolgreicher Angriff kann Sitzungs-Übernahmen, Daten-Abfluss und manipulierte Inhalte nach sich ziehen – mit unmittelbarem Schaden für Vertrauen und Rechtssicherheit. Die Abwehr kostet vor allem Sorgfalt in der Entwicklung und ist weitaus günstiger als die Folgen eines Vorfalls. Eine dokumentierte Schutz-Strategie aus Ausgabe-Maskierung und CSP ist im Schadens-Fall zugleich ein Beleg für die erfüllte Sorgfalts-Pflicht im Sinne der DSGVO.
Typische Fehler
- Nutzer-Eingaben ungeprüft wieder ausgeben – die klassische und häufigste Ursache.
- Sich allein auf Prüfungen im Browser verlassen – die lassen sich umgehen, die Absicherung muss auf dem Server passieren.
- Nur sichtbare Felder absichern und Parameter aus der Adresszeile übersehen.
- Auf eine Content-Security-Policy als zusätzliche Schutz-Schicht verzichten.
- Bestehende Funktionen nach Änderungen nicht erneut auf Einschleus-Möglichkeiten testen.
Worauf achten?
- Jede Ausgabe kontextgerecht maskieren – im HTML anders als in einem Attribut oder im Skript-Kontext.
- Eingaben auf dem Server prüfen, nicht nur im Browser.
- Eine Content-Security-Policy als zweite Verteidigungslinie einsetzen.
- Auch Parameter aus der Adresszeile und aus Verweis-Quellen als unsicher behandeln.
- Sicherheits-Tests fest in den Entwicklungs-Ablauf aufnehmen, nicht nur einmalig prüfen.
Häufig gestellte Fragen
Was ist Cross-Site-Scripting?
Eine Angriffsart, bei der fremder Skript-Code in eine Website eingeschleust und im Browser der Besucher ausgeführt wird – meist, weil Eingaben ungeprüft wieder ausgegeben werden. Ziel sind oft Sitzungs-Daten oder Eingaben.
Welche Arten von XSS gibt es?
Reflektiertes XSS (über einen manipulierten Link, sofort zurückgespiegelt), persistentes XSS (dauerhaft gespeichert, etwa in einem Kommentar) und DOM-basiertes XSS (entsteht durch unsichere Verarbeitung im Browser selbst).
Wie schützt man sich vor XSS?
Durch konsequentes, kontextgerechtes Maskieren aller Ausgaben auf dem Server und ergänzend durch eine Content-Security-Policy, die das Ausführen nicht freigegebener Skripte im Browser unterbindet. Beide Maßnahmen wirken zusammen.
Reicht eine CSP allein gegen XSS?
Nein. Eine Content-Security-Policy ist eine wirksame zweite Schutz-Schicht, ersetzt aber nicht die saubere Ausgabe-Maskierung. Erst beide zusammen bieten verlässlichen Schutz.