Was ist Cross-Site-Scripting (XSS)?

XSS: Definition und Ursache

Eine Website wird verwundbar, wenn sie Eingaben von Nutzern ungeprüft in ihre Seiten einbaut – etwa Kommentare, Suchbegriffe oder Profilangaben. Enthält die Eingabe Skriptcode, führt der Browser des nächsten Besuchers ihn aus, als gehöre er zur Seite. Damit gelten für den Code dieselben Rechte wie für den legitimen Seitencode.

XSS gehört seit Jahren zu den häufigsten Schwachstellen von Webanwendungen und wird in den OWASP Top 10 der Kategorie Injection zugerechnet. Anders als bei SQL-Injection ist nicht der Server das unmittelbare Ziel, sondern die Besucher und Administratoren der Website.

Die drei Arten von XSS

Beim gespeicherten (stored) XSS wird der Schadcode dauerhaft abgelegt, etwa in einem Kommentar, und trifft jeden, der die Seite aufruft. Beim reflektierten (reflected) XSS steckt er in einem präparierten Link, der zum Beispiel per Phishing-Mail verschickt wird. Beim DOM-basierten XSS entsteht die Lücke erst durch JavaScript im Browser, das Daten unsicher in die Seite schreibt.

• Übernahme von Sitzungen und Benutzerkonten
• Mitlesen von Eingaben, etwa Passwörtern oder Zahlungsdaten
• Einblenden gefälschter Formulare auf der echten Seite
• Weiterleitung auf Schadseiten
• Angriffe auf Administratoren über das Backend

Praxis­bei­spiel: Die Bewertung im Online­shop

Ein Onlineshop erlaubt Produktbewertungen und gibt den Text ungefiltert wieder. Ein Angreifer hinterlegt statt einer Bewertung ein kleines Skript. Öffnet später ein Shop-Administrator die Bewertung im Backend, könnte das Skript dessen Sitzungsschlüssel abgreifen und dem Angreifer den Zugang zur Verwaltung verschaffen.

Der Shop schützt sich, indem er Ausgaben je nach Kontext kodiert, sodass Skripte nur als Text erscheinen, Sitzungs-Cookies mit den Attributen HttpOnly und SameSite absichert und eine Content Security Policy (CSP) einsetzt, die nur erlaubte Skriptquellen zulässt. Das Backend bereinigt Bewertungen zusätzlich vor der Anzeige.

Schutz, Grenzen und Umsetzung

Wichtigste Maßnahme ist die kontextgerechte Ausgabekodierung: Daten werden vor der Anzeige so maskiert, dass der Browser sie als Text und nicht als Code behandelt. Moderne Frameworks wie React tun das standardmäßig, solange Entwickler es nicht gezielt umgehen. Die CSP begrenzt den Schaden, wenn doch etwas durchrutscht; erlaubtes HTML, etwa aus Texteditoren, wird mit geprüften Bibliotheken bereinigt.

Nano Concepts prüft Webanwendungen und Shops auf XSS, behebt Lücken im Code und in Plugins und richtet sicherheitsrelevante HTTP-Header wie die Content Security Policy ein. Bei neuen Projekten achten wir von Anfang an darauf, dass Nutzereingaben nie ungeprüft in Seiten gelangen.

• Eingaben ungeprüft in Seiten ausgeben, vor allem in Kommentaren und Suchfeldern
• innerHTML oder vergleichbare Funktionen mit Nutzerdaten verwenden
• Nur auf Eingabefilter statt auf Ausgabekodierung setzen
• Drittanbieter-Skripte und Plugins ohne Prüfung einbinden
• Keine Content Security Policy und keine abgesicherten Cookies