Was ist XSS?

Cross-Site Scripting (XSS) einfach erklärt

Webseiten zeigen oft Inhalte an, die von Nutzenden stammen: Kommentare, Produktbewertungen, Suchbegriffe oder Profilnamen. Prüft die Anwendung diese Inhalte nicht sorgfältig, kann ein Angreifer statt eines harmlosen Textes ein kleines Programm einschleusen. Meist ist es in JavaScript geschrieben – der Programmiersprache, mit der Browser Webseiten interaktiv machen.

Der Browser des nächsten Besuchers kann nicht unterscheiden, ob das Skript von der Website oder vom Angreifer stammt. Er führt es einfach aus – mit allen Rechten, die die Website bei diesem Besucher hat.

Ein Vergleich: Stellen Sie sich ein Schwarzes Brett vor, an dem jeder Zettel aufhängen darf. Ein Unbekannter hängt dort eine Anweisung auf, die wie eine offizielle Mitteilung der Hausverwaltung aussieht. Menschen werden vielleicht stutzig – der Browser nicht. Er befolgt jede Anweisung, die auf der Seite steht.

So funktioniert XSS

Man unterscheidet drei Varianten:

1. Gespeichertes XSS (stored): Der Schadcode wird dauerhaft in der Anwendung gespeichert, etwa in einem Kommentar, und trifft jeden, der die Seite aufruft.
2. Reflektiertes XSS (reflected): Der Schadcode steckt in einem präparierten Link, oft verschickt per Phishing-Mail. Die Anwendung gibt ihn ungeprüft zurück, sobald das Opfer den Link öffnet.
3. DOM-basiertes XSS: Die Lücke steckt im JavaScript der Seite selbst, das Daten etwa aus der Adresszeile unsicher in die Seite einbaut. DOM steht für die innere Struktur einer Webseite im Browser.

Ist das Skript aktiv, handelt es im Namen des Opfers: Es kann Sitzungsdaten auslesen, also die Information, dass jemand gerade angemeldet ist. Außerdem kann es Eingaben wie Passwörter mitschneiden, Inhalte verändern oder Aktionen auslösen – etwa eine Bestellung oder eine Passwortänderung. In den OWASP Top 10, der bekanntesten Liste typischer Schwachstellen in Webanwendungen, zählt XSS zur Kategorie Injection.

Ein Beispiel aus der Praxis

Ein Online-Shop für Fahrradzubehör bietet Produktbewertungen an. Ein Angreifer schreibt in eine Bewertung neben ein paar lobenden Worten ein kurzes Skript. Der Shop speichert die Bewertung ungeprüft.

Bevor Bewertungen erscheinen, gibt eine Mitarbeiterin sie im Verwaltungsbereich frei. Beim Öffnen führt ihr Browser das Skript aus. Es schickt ihr Sitzungs-Cookie an den Angreifer – eine Art digitale Eintrittskarte, die der Shop nach der Anmeldung ausstellt. Damit meldet sich der Angreifer als Administratorin im Shop an, ohne ihr Passwort zu kennen.

Die Ursache: Der Shop zeigt Bewertungen an, ohne sie vorher unschädlich zu machen. Zusätzlich fehlte beim Cookie das Attribut HttpOnly, das Skripten den Zugriff darauf verwehrt hätte.

Warum ist das für Unternehmen wichtig?

XSS trifft nicht den Server, sondern die Menschen, die Ihre Anwendung nutzen – Kunden, Beschäftigte, Administratoren. Gerade das macht die Lücke heikel: Angriffe laufen unter Ihrem Namen und auf Ihrer vertrauenswürdigen Domain. Ein gefälschtes Anmeldeformular auf der echten Website ist für Betroffene kaum zu erkennen.

Die Folgen reichen von übernommenen Kundenkonten über abgegriffene Zugangs- und Zahlungsdaten bis zur Übernahme von Administratorkonten. Sind personenbezogene Daten betroffen, kann zudem eine Meldepflicht nach der DSGVO entstehen. Hinzu kommt der Imageschaden, wenn Ihre Website zur Falle für die eigenen Kunden wird.

So schützen Sie sich

• Ausgaben kodieren: Wandeln Sie Inhalte vor der Anzeige passend zum Kontext um, damit der Browser sie als Text und nicht als Code behandelt (Output-Encoding).
• Eingaben prüfen: Akzeptieren Sie nur, was ein Feld erwarten darf – etwa Ziffern in einer Postleitzahl.
• Sichere Frameworks nutzen: Moderne Web-Frameworks, also Programmiergerüste für Webanwendungen, kodieren Ausgaben standardmäßig. Vermeiden Sie Funktionen, die Inhalte ungefiltert als Seitencode einfügen.
• Content Security Policy (CSP): Diese Sicherheitsrichtlinie legt fest, aus welchen Quellen der Browser Skripte laden darf, und begrenzt so den Schaden.
• Cookies schützen: Versehen Sie Sitzungs-Cookies mit den Attributen HttpOnly (kein Zugriff für Skripte) und Secure (Übertragung nur verschlüsselt).
• Zusätzliche Schutzschicht: Eine WAF fängt viele Angriffsversuche ab, ersetzt aber keine saubere Programmierung.
• Regelmäßig testen: Lassen Sie Anwendungen vor dem Livegang und nach größeren Änderungen prüfen – automatisierte Scans (DAST) ergänzt um manuelle Tests.

Wie Rootsektor unterstützt

Im Penetrationstest für Webanwendungen & Webshops prüfen wir gezielt auf alle drei XSS-Varianten – auch an Stellen, die automatisierte Scanner leicht übersehen, etwa in mehrstufigen Formularen oder im Verwaltungsbereich. Jeder Befund wird mit Nachweis, Bewertung nach CVSS und konkreter Maßnahmenempfehlung dokumentiert. Kritische Schwachstellen melden wir schon während des Tests sofort an Ihre vereinbarte Ansprechperson. Ihr Festpreisangebot nach dem Scoping erhalten Sie über unser Pentest-Angebot.