Cross-Site Scripting (XSS) bezeichnet das Ausnutzen einer Computersicherheitslücke, 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 sind. Aus diesem vertrauenswürdigen Kontext kann dann ein Angriff gestartet werden.
Die Bezeichnung Cross-Site leitet sich von der Art ab, wie diese Attacke Webseiten-übergreifend ausgeführt wird (auf einer vom Angreifer kontrollierten Seite steht beispielsweise ein präparierter Hyperlink, der zur vermeintlich vertrauenswürdigen Website einer meist ahnungslosen dritten Partei führt).
Cross-Site Scripting wird manchmal auch "CSS" abgekürzt, hat jedoch nichts mit der Cascading Style Sheet-Technologie zu tun, die weit häufiger CSS genannt wird.
Funktionsweise
Clientseitig
Beim clientseitigen Cross-Site Scripting wird Code auf Seite des Clients ausgeführt, etwa dem Webbrowser oder E-Mail-Programm. Daher muss der Angreifer seinem Opfer einen präparierten Hyperlink zukommen lassen, den er zum Beispiel in eine Webseite einbindet oder in einer E-Mail versendet. Es werden häufig URL Spoofing-Techniken und Kodierungsverfahren eingesetzt, um den Link unauffällig oder vertrauenswürdig erscheinen zu lassen.
Ein klassisches Beispiel für clientseitiges Cross-Site Scripting ist die Übergabe von Parametern an ein CGI-Skript einer Website. So ist es unter Umständen möglich, manipulierte Daten an den Benutzer zu senden. Diese Daten sind oft Code einer clientseitigen Skriptsprache, die als Parameter an eine Website übergeben werden. Wenn dieser Code dann in der vom Server zurückgesendeten Webseite wieder auftaucht, kann es dazu führen, dass der Webbrowser des Benutzers diesen Code ausführt. Dies kann erreicht werden, indem Daten in ein Formular auf der Seite eingegeben werden, das normalerweise als Eingabefenster für ein Webforum dient, oder indem eine URL mit dem Code als Parameter veröffentlicht wird, auf die die User klicken (z. B. in E-Mails oder im Usenet).
Gefährlich wird dies, wenn die Website, auf der der Code untergebracht wurde, im lokalen Browser mit besonderen Sicherheitsrechten (Privilegien) ausgestattet ist. Der Code kann dann in Abhängigkeit von der Mächtigkeit der Skriptsprache verschiedene Dinge tun, die mit den Rechten des lokalen Benutzers möglich sind. Alternativ kann der Code auch Cookies mit Anmeldeinformationen stehlen.
Da aus Bequemlichkeitsgründen auf Microsoft Windows-Systemen der lokale Benutzer häufig mit Administrator-Rechten ausgestattet ist, ist dies bereits eine potenziell 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.
Serverseitig
Beim serverseitigen Cross-Site Scripting wird versucht Code auf dem Server auszuführen. Dies ist z. B. durch PHPs oder Javas "include"-Anweisungen möglich. Unter PHP und Java ist es möglich, Dateien von anderen Rechnern einzubinden, also auch von einem Rechner eines Angreifers. Etliche Programmiersprachen wie Perl bieten die Möglichkeit, lokal Programme über eine Shell auszuführen. Wird ein lokales Programm mit benutzermanipulierbaren Parametern aufgerufen und die Parameter nicht entsprechend gefiltert, ist es möglich weitere Programme aufzurufen. So können etwa Dateien geändert oder sensible Daten ausgespäht werden.
Neuerdings werden Webspider, wie der Google Suchroboter, missbraucht, um serverseitige 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 Systemes auf.
Schutz
Um sich vor einer XSS-Attacke zu schützen, ist es als Programmierer erforderlich, die einkommenden Daten zu überprüfen. Hier treffen die Zitate eines Microsoft-Mitarbeiters zu, der ein Buch Never trust the client und sein nächstes bereits All incoming data is EVIL nannte. Wie kann man diese Klimax erklären? Jegliche Daten, die einmal beim Client, d.h. beim Besucher der Website, waren, sind potenziell verseucht. So könnte sich beispielsweise ein Mitglied in einem Forum hallo<script>alert("test");</script> nennen. Bei fehlerhafter Auswertung dieser Daten (in PHP beispielsweise per htmlentities()) wird das Script in dieser Form mit an den Browser geschickt, der eine Seite aufruft, auf der unser Mitglied etwas geschrieben hat. Der Betrachter der Seite sieht lediglich als Anzeige hallo - erhält jedoch eine nervige Box mit der Schrift "test". Wären die HTML-Steuerzeichen < und > in > bzw. < umgewandelt worden, so hätte der Browser das Script nicht ausgeführt, sondern als Text dargestellt.
Möglich hierbei wäre z.B. auch, im Benutzernamen ein HTML-Bild-Tag von der Größe 1x1 zu geben und per JavaScript das Attribut SRC dieses Bildes zu ändern - und "zufällig" das Sessioncookie des Benutzers auszulesen und mit an die URL des Bildes zu hängen. Folgerichtig darf eine HTML-Eingabe des Benutzers nicht unversehens an andere Benutzer zurückgeschickt werden. Auch das Verbot des <script>-Tags führt nicht zum Erfolg, da in einem <img>-Tag im src Attribut beispielsweise trotzdem JavaScript ausgeführt werden kann.
"Sicher" auf der Clientseite ist man sicherlich nie - sicherer ist man jedoch mit ausgeschaltetem JavaScript oder mit einem Textbrowser wie Lynx
Siehe auch: SQL Injection, Computersicherheit, CGI