Cross-Site-Scripting (XSS; deutsch Webseitenübergreifendes Skripting) bezeichnet das Ausnutzen einer Computersicherheitslücke in Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als vertrauenswürdig eingestuft werden. Aus diesem vertrauenswürdigen Kontext kann dann ein Angriff gestartet werden.
Ziel ist es meist, an sensible Daten des Benutzers zu gelangen, um beispielsweise seine Benutzerkonten zu übernehmen (Identitätsdiebstahl).
Eine spezielle Anwendung des XSS ist das Cross-Site-Tracing.
Die Bezeichnung „Cross-Site“ bezieht sich darauf, dass der Angriff zwischen verschiedenen Aufrufen einer Seite stattfindet, in der Regel jedoch nicht darauf, dass unterschiedliche Websites beteiligt sind. Meist werden für diese Angriffsart aufgrund ihrer weiten Verbreitung Script-Sprachen – insbesondere JavaScript – genutzt: daher „Scripting“.
Das X wird im Englischen als Abkürzung für cross (= „Kreuz“) verstanden.
Trotz der Namensähnlichkeit sind das Cross-Site-Cooking und die Cross-Site-Request-Forgery sowie deren Anwendungen wie etwa die Cross-Site-Authentication-Attacke keine Formen von Cross-Site-Scripting.
Cross-Site-Scripting ist eine Art der HTML Injection. Cross-Site-Scripting tritt dann auf, wenn eine Webanwendung Daten annimmt, die von einem Nutzer stammen, und diese Daten dann an einen Browser weitersendet, ohne den Inhalt zu überprüfen. Damit ist es einem Angreifer möglich, auch Skripte indirekt an den Browser des Opfers zu senden und damit Schadcode auf der Seite des Clients auszuführen.
Ein klassisches Beispiel für Cross-Site-Scripting ist die Übergabe von Parametern an ein serverseitiges Skript, das eine dynamische Webseite erzeugt. Dies kann etwa das Eingabeformular einer Webseite sein, wie in Webshops, Foren, Blogs und Wikis üblich. Die eingegebenen Daten werden auf der Webseite wieder als Seiteninhalt ausgegeben, wenn die Seite von Benutzern aufgerufen wird. So ist es möglich, manipulierte Daten an alle Benutzer zu senden, sofern das Serverskript dies nicht verhindert. Diese Daten sind oft Code einer clientseitigen Skriptsprache (meist JavaScript).
Häufige Angriffsarten sind das Entführen von Benutzer-Sessions, Website-Defacements, das Einstellen negativer Inhalte, Phishing-Angriffe und die Übernahme der Kontrolle des Benutzerbrowsers.
Besonders gefährlich wird dies, wenn die Webseite, auf der der Schadcode untergebracht wurde, im lokalen Browser mit besonderen Sicherheitsrechten (Privilegien) ausgestattet ist. Der Schadcode kann dann in Abhängigkeit von der Mächtigkeit der Skriptsprache verschiedene Dinge tun, die mit den Rechten des lokalen Benutzers möglich sind. Da aus Bequemlichkeit auf Microsoft-Windows-Systemen (vor Windows Vista) der lokale Benutzer häufig mit Administrator-Rechten ausgestattet ist, ist dies bereits eine sehr gefährliche Konstellation. Aber auch ohne Administrator-Rechte kann der Angreifer versuchen, durch Ausnutzung von Sicherheitslücken bei der Ausführung der betreffenden Skriptsprache diese Rechte zu erlangen.
In der Regel wird XSS etwa in Foren breit gestreut und nicht zielgerichtet an ausgewählte Personen gerichtet. Dies ist jedoch ebenfalls möglich. Neben dem klassischen XSS im Webbrowser interpretieren häufig auch E-Mail-Programme Scriptcode, was einen Angriff per E-Mail ermöglicht. Dazu schiebt der Angreifer dem Opfer ein von ihm präpariertes HTML-Dokument unter, das per E-Mail verschickt wird. Oder der Angreifer lässt dem Opfer einen Hyperlink zukommen, der auf eine vom Angreifer präparierte Webseite weist oder selbst den Schadcode enthält. Häufig werden dazu auch Kurz-URLs, URL-Spoofing-Techniken und andereKodierungsverfahren eingesetzt, um den Link zu verschleiern oder vertrauenswürdig erscheinen zu lassen.
Neuerdings werden auch Webspider missbraucht, um XSS- und SQL-Injection-Attacken auszuführen. Hierzu wird ein präparierter Link auf einer Webseite veröffentlicht. Sobald ein Webspider diesem Link folgt, löst er die Attacke aus. Dadurch taucht die IP-Adresse des Spiders und nicht die des eigentlichen Angreifers in den Protokollen des angegriffenen Systems auf. Der Angreifer kann somit anonym agieren. In schwerwiegenden Fällen wäre es aber dennoch möglich, die IP-Adresse des Computers, der den manipulierten Link veröffentlicht hat, herauszufinden.
Um durch eine Webanwendung keine Basis für XSS-Angriffe zu bieten, müssen alle eingehenden Eingabewerte als unsicher betrachtet und vor der weiteren Verarbeitung auf der Serverseite geprüft werden. Dabei sollte man sich nicht darauf verlassen, „böse“ Eingaben zu definieren (Schwarze Liste), um diese herauszufiltern, da man nicht genau wissen kann, welche Angriffsmethoden es gibt. Besser ist es daher, die „guten“ Eingaben exakt zu definieren (Weiße Liste) und nur solche Eingaben zuzulassen. Dieses Verfahren zählt ganz allgemein zu den Best Practices der Programmierung und sollte wo immer möglich angewandt werden, um unerwartetes Programmverhalten zu verhindern. Allerdings ist es je nach Anwendung nicht immer ohne weiteres in der Praxis umzusetzen, besonders wenn die erlaubten Eingabewerte sehr zahlreich sind.
Eine DOM-Injection zu verhindern, ist weit weniger einfach, da Benutzereingaben nicht serverseitig geprüft werden können. Da dieser Angriff unter Umgehung des Servers stattfindet, muss die Gültigkeitsprüfung für Eingabedaten auf Clientseite im Browser erfolgen, was allerdings wiederum leicht manipulierbar ist.