Cross-Site-Scripting schleust Schadcode in Webseiten ein, der im Browser anderer Nutzer ausgeführt wird – um Sitzungen zu übernehmen, Eingaben abzugreifen oder Aktionen auszulösen.
Cross-Site-Scripting – abgekürzt XSS – ist eine Schwachstelle in Webanwendungen, bei der ein Angreifer eigenen Code (meist JavaScript) in eine Seite einschleust, der anschließend im Browser anderer Nutzer ausgeführt wird. Anders als bei der SQL-Injection, die auf die Datenbank zielt, richtet sich XSS gegen die Besucher der Anwendung. Der eingeschleuste Code läuft im Sicherheitskontext des Opfers und kann alles tun, was auch legitimer Seiten-Code darf: Sitzungs-Cookies auslesen, Eingaben mitschneiden, Inhalte verändern oder im Namen des Opfers Aktionen auslösen.
XSS steht seit Jahren in den OWASP Top 10. Die Ursache ist stets dieselbe: Von Nutzern stammende Inhalte werden in eine Seite eingebaut, ohne sie zuvor korrekt zu behandeln. Der Browser kann dann nicht mehr zwischen dem Code des Entwicklers und dem des Angreifers unterscheiden.
Varianten
- Stored (persistent): Der Schadcode wird dauerhaft gespeichert – etwa in einem Kommentar, Profilfeld oder Supportticket – und bei jedem Aufruf an alle Betrachtenden ausgeliefert. Dies ist die gefährlichste Form, weil sie viele Opfer ohne weiteres Zutun erreicht.
- Reflected (reflektiert): Der Code steckt in einem präparierten Link oder Formular und wird nur an die Person ausgeliefert, die ihn aufruft. Er wird typischerweise über Phishing verteilt.
- DOM-basiert: Die Schwachstelle liegt im clientseitigen JavaScript, das Eingaben unsicher verarbeitet; der Server sieht den Schadcode unter Umständen gar nicht.
Ein häufiges Ziel ist der Diebstahl von Sitzungs-Cookies: Gelingt er, übernimmt der Angreifer die angemeldete Sitzung, ohne Passwort oder zweiten Faktor zu benötigen. Gegen besonders schützenswerte Konten – etwa Administratoren einer Verwaltungsoberfläche – ist das besonders folgenreich.
Bedeutung für Unternehmen
XSS wird gern unterschätzt, weil es „nur“ im Browser stattfindet. Tatsächlich ist es ein Einstieg in die Übernahme von Benutzer- und Administratorkonten einer Anwendung und damit in den Zugriff auf alle Daten, die diese Konten sehen. Besonders kritisch ist XSS in internen Verwaltungsoberflächen und in Portalen, über die Kunden sensible Daten verwalten. Der typische Fehler ist uneinheitliche Ausgabekodierung: An vielen Stellen korrekt, an einer vergessenen nicht – und diese genügt.
In unseren Penetrationstests prüfen wir XSS im Zusammenspiel mit anderen Schwächen. Oft entsteht der eigentliche Schaden erst aus der Kette – etwa, wenn sich über XSS die Sitzung eines Administrators kapern und darüber die gesamte Anwendung kontrollieren lässt.
Schutz und Prüfung
- Ausgaben kontextgerecht kodieren: Benutzerinhalte beim Einfügen in HTML, Attribute, JavaScript oder URLs jeweils passend maskieren – die zentrale Gegenmaßnahme.
- Content Security Policy (CSP): Eine restriktive CSP begrenzt, welcher Code überhaupt ausgeführt werden darf, und entschärft viele XSS-Fälle.
- Cookies absichern: Sitzungs-Cookies mit den Attributen HttpOnly und Secure versehen, damit Skripte sie nicht auslesen können.
- Moderne Frameworks nutzen: Aktuelle Web-Frameworks kodieren Ausgaben standardmäßig – gefährlich wird es dort, wo Entwickler diese Mechanismen bewusst umgehen.
- Regelmäßig prüfen: XSS entsteht mit jeder neuen Eingabestelle neu; wiederkehrende Tests und ein Retest nach der Behebung sichern den Stand ab.