Netsolution

Cross-Site Scripting (XSS) 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 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 Website-ü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

Beim 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 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.

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 Systemes auf. Der Angreifer kann somit anonym agieren.

Beispiel

Ein Angreifer meldet sich in einer Website an, von der aus er Daten sammeln möchte. Bei der Wahl seines Benutzernamens gibt er hallo<script>alert("test");</script> an. Wird dieser Benutzername nun unverändert ausgegeben, würde er von Browsern als Text „hallo“ und als script-Element interpretiert, wobei nur ersteres sichtbar wäre. Letzteres wird jedoch vom Browser als clientseitiges Code interpretiert und ausgeführt. In diesem Beispiel würde der Code zwar nur einen harmlosen Warnhinweis-Dialog mit dem Text „test“ öffnen, doch es kann auch Code eingeschleust werden, der auch andere Cross-Site-Angriffe ermöglicht.

Schutz 

Um eine Webanwendung vor einem XSS-Angriff zu schützen, müssen alle eingehenden Parameterwerte als unsicher betrachtet und vor der weiteren Verarbeitung auf 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.

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. Jegliche Daten, die einmal beim Client, d. h. beim Besucher der Website, waren, sind demnach potenziell verseucht.

Als Schutz bei einer HTML-Ausgabe ist es nötig, die HTML-Metazeichen (insbesondere „<“ und „>“) durch entsprechende Zeichenreferenzen zu ersetzen, damit sie als normale Zeichen und nicht als Metazeichen behandelt werden.

Durch Einsatz von Web Application Firewalls (WAF) können zumindest in der Theorie einfache (primitive) XSS Attacken verhindert werden. Praktisch sind sichere Anwendungen jeder WAF vorzuziehen.

PHP

Klassen und Funktionen zum Schutz vor XSS