zurück zum Artikel

Cross-Site-Scripting: Datenklau über Bande

Daniel Bachfeld

Nicht immer muss ein Buffer Overflow herhalten, um unerlaubt Befehle irgendwo einzuschleusen und auszuführen. Neue Angriffstechniken transportieren ausführbaren Code sogar in Hyperlinks.

Vier Dinge spielen im Schaustück Cross-Site-Scripting (XSS) die Hauptrollen: Ein Angreifer mit einem manipuliertem Hyperlink, eine Web-Applikation die dynamische Seiten ausliefert, ein Webclient mit aktiviertem JavaScript und ein Cookie mit Benutzerdaten. Im Mittelpunkt steht die Web-Applikation, die Seiten aus Benutzereingaben generiert, die an sie gesendet werden:

http://www.vertrauenswürdige.seite/cgi-bin
              /test.cgi?irgendwas

Variablen in einer URL zu übertragen, ist durchaus üblich und wird in HTTP mit der GET-Methode unterstützt. Auf der Serverseite wird ein Skript gestartet, welches die Variable einliest, eine neue Seite generiert und an den Webbrowser sendet. Das obige Beispiel findet sich zum Beispiel in der Apache-Standardinstallation. Das Skript test.cgi gibt die Umgebungvariablen aus, die es in einem sogenannten Hash gespeichert hat:

print "%ENV:\n", map { "$_ = $ENV{$_}\n" } keys %ENV;

Darüberhinaus zeigt es auch den sogenannten Query-String hinter dem Fragezeichen an "irgendwas", Benutzereingaben werden also an den Browser zurückgesendet. Geschieht dies wie hier, völlig ungefiltert, so kann ein kleines JavaScript als Argument in der URL an den Server übertragen werden. Dieser verpackt es in ein HTML-Dokument und sendet es zurück. Das Echo kann verheerende Folgen haben, wenn der Code im Browser ausgeführt wird.

Beim Test-Skript des Apache wird niemand dem Programmierer einen Fehler vorwerfen. Bei Webshops, Webmailern und Portalen sieht die Sache etwas anders aus, hier sollten die Argumente sorgfältig gefiltert werden.

Folgendes Skript öffnet ein kleines Fenster mit dem Text "Überraschung" und einem OK-Button zum Schließen:

http://www.vertrauenswürdige.seite/cgi-bin
               /test.cgi?<script>alert("Überraschung")</script>

Das Skript hätte natürlich auch in einem HTML-Dokument auf dem Server eingebettet sein können, wo ist also das Problem? Aus Sicherheitsgründen ist JavaScript oft nur für benutzerdefinierte, vertrauenswürdige Webserver zugelassen oder der IE fragt bei jedem Skript explizit nach, ob es ausgeführt werden soll. Nur wenn der Browser JavaScript von solch einem Server empfängt, wird es ausgeführt. Der Browser entscheidet dies anhand der gesendeten URL.

Der Trick des Angreifers besteht darin, dem Browser vorzugaukeln, das JavaScript stamme von einer vertrauenswürdigen Seite. Auf einem beliebigen Webserver oder in einem HTML-Dokument hat er einen Hyperlink mit JavaScript eingebettet. Der Link zeigt auf einen Server, von dem der Angreifer annimmt, dass ein Opfer diesen zu den Vertrauenswürdigen zählt, zum Beispiel eine Bank. Zusätzlich weiß der Angreifer, dass dieser Server eine XSS-Schwäche hat. Klickt das Opfer den Link an, wird es zu der Seite geleitet und das JavaScript wird ohne Rückfrage im Browser ausgeführt.

Ein Klick auf einen vertrauten Hyperlink führt zur vermeintlich sicheren Webseite

Normalerweise darf JavaScript nur Cookies auf der Festplatte des Benutzers anfassen, vorausgesetzt das Skript stammt vom gleichen Server (Origin) wie der Cookie. Cookies können Sitzungsnummern (Session-ID) oder Authentifizierungsdaten enthalten und werden von Webservern auf dem Client abgelegt und abgefragt. Viele Webseiten und Internetshops verwenden Cookies, zum Beispiel Amazon und eBay. Mit Cross-Site-Scripting ist ein Angreifer in der Lage, Cookies einzusehen, zu manipulieren oder zu löschen.

Der Griff in die Keksdose erscheint auf den ersten Blick harmlos, ist es aber nicht. Um eine Verbindung zwischen Webserver und Client nach einer erfolgreichen Authentifizierung zu kennzeichnen, verwendet man Session-IDs, die man anderem in Cookies ablegt. Schafft es ein Angreifer solch ein Cookie zu stehlen, kann er die ID extrahieren und eine gültige Verbindung mit dem Server aufbauen, ohne sich mit Name und Passwort anmelden zu müssen. Allerdings muss die ID gültig sein, das heißt der Angriff muss im gleichen Zeitraum erfolgen, in dem das Opfer angemeldet ist. Nach der Abmeldung ist die Session-ID ungültig. David Endler, Sicherheitsexperte bei iDefense, zeigt in [2] wie man Benutzerdaten aus Cookies ausliest, die man über automatisierte XSS-Attacken [1] gestohlen, beziehungsweise kopiert hat. Die dort aufgeführten Beispielskripte verschicken in URLs eingebettetes JavaScript per HTML-Mails und sammeln gestohlene Cookies ein.

Folgender Link demonstriert eine XSS-Schwäche der Suchmaschine Overture: XSS-Demo [1]. [Update]: Mittlerweile hat Overture seine Such-Applikation gefixt; der übergebene JavaScript-Code wird nur noch dargestellt und nicht mehr ausgeführt.[/Update]

Overture filtert in der URL übergebene Argumente nicht richtig aus. Das eingebettete JavaScript sieht folgendermaßen aus:

<script>
alert("Achtung XSS Attacke http://www.heisec.de");
</script>
<SCRIPT>alert(document.domain);</SCRIPT>
<SCRIPT>alert(document.cookie);</SCRIPT>
<iframe src="http://www.heisec.de">

Sonderzeichen wie <>"; müssen dabei mit Escape-Sequenzen dargestellt werden. Wie das dann aussieht, können Sie in der URL der neuen Seite bewundern. Das Skript öffnet hintereinander drei Fenster, die eine Warnmeldung, die Herkunft der HTML-Seite und das zugehörige Cookie anzeigen. Darüberhinaus wird in einem Frame die Startseite von heise Security angezeigt. Das Einschleusen von beliebigen HTML-Code in angezeigte Dokumente nennt man HTML-Injection.

Aus dem Rahmen fallen

Aus dem Rahmen fallen

Durch ungepatchte Sicherheitslöcher in Web-Browsern kann JavaScript aber auch mehr als nur Cookies stehlen. Inbesondere der Internet Explorer, der Microsofts JavaScript-Erweiterung JScript ausführen kann, hat eine Reihe von Schwachstellen, die sich durch Skripting ausnutzen lassen. JavaScript kann auf alle Elemente einer HTML-Seite zugreifen, sie verändern oder auch neue hinzufügen -- allerdings nur dann, wenn beide Seiten aus der gleichen Domain stammen ("same-Origin-Prinzip"). So könnte JavaScript-Code auf dieser Seite den Inhalt einer gleichzeitig geöffneten heise-online-Seite modifizieren. Eine Reihe von Fehlern im Internet Explorer erlaubten es allerdings schon öfter, dieses same-Origin-Konzept zu umgehen. Damit war es dann einer Web-Seite möglich, andere Seiten "fernzusteuern" auch wenn sie aus anderen Quelle stammen. Ein Extremfall war ein Bug, der es ermöglichte, ein Hilfefenster zu öffnen und zu manipulieren. Dieses war dann mit den Rechten des lokalen Rechners ausgestattet und konnte damit auch auf lokale Dateien zugreifen. Bei solchen Fehlern spricht man von Cross-Frame- beziehungsweise Cross-Windows-Scripting. Ob der eigene Browser für solche Angriffe verwundbar ist, kann man auf den Seiten des c't-Browserchecks [2] sehen. Mit einigen der Sicherheitslöcher ist der Zugriff auf lokale Dateien und sogar das Ausführen beliebiger Programme möglich. Die Konsequenzen kann sich jeder selbst ausmalen.

Cross-Site-Scripting-Attacken haben ihre Ursache in fehlerhaften Web-Applikationen, während Cross-Frame-Scripting-Attacken auf Sicherheitslücken im Web-Browser beziehungsweise in den Skripting-Funktionen zurückzuführen sind. Insbesondere die Kombination von Schwachstellen auf Server und Client gibt einem Angreifer die Chance, die Kontrolle über einen PC zu erlangen. Die Mehrzahl der IE-Installation dürfte Active Scripting aktiviert haben. Ein sicherer Schutz wäre das Deaktivieren aller Skripting-Funktionen. Als Empfehlung kann das nicht gelten, schließlich werden viele Webseiten dann nicht mehr korrekt dargestellt. Durch das Einspielen aktueller Patches kann man aber die Hürden für einen Angreifer erhöhen.

[1] Evolution of Cross-Site Scripting Attacks [3]

[2] Brute-Force Exploitation of Web Application Session IDs [4]

[3] XSS-FAQ [5]

[4] About Cross-Frame Scripting and Security [6] (dab [7])

URL dieses Artikels:
https://www.heise.de/-270244

Links in diesem Artikel:
[1] http://www.overture.com/d/search/;$sessionid$EVV5ZDIABJG13QFIEEOQPUQ?Keywords=%3cscript%3ealert%28%22Achtung%20+XSS+Attacke%2d+http%3a%2f%2fwww.heisec.de%22%29%3c%2fscript%3e%3cSCRIPT%3ealert%28document.domain%29%3b%3c%2fSCRIPT%3e%3cSCRIPT%3ealert%28document.cookie%29%3b%3c%2fSCRIPT%3e%3ciframe+src%3d%22http%3a%2f%2fwww.heisec.de%22%3e%3c%2fiframe%3e
[2] http://www.heise.de/security/dienste/browsercheck
[3] http://www.idefense.com/XSS.html
[4] http://www.idefense.com/idpapers/SessionIDs.pdf
[5] http://www.cgisecurity.com/articles/xss-faq.txt
[6] http://msdn.microsoft.com/library/default.asp?url=/workshop/author/om/xframe_scripting_security.asp
[7] mailto:dab@ct.de

Copyright © 2003 Heise Medien