Cross-Site-Scripting: Datenklau über Bande
Angriffe auf Web-Clients mit Cross-Site- und Cross-Frame-Scripting
Daniel Bachfeld - 06.08.2003
Ein scheinbar harmloser Klick auf einen Hyperlink und Cookies, Passwörter und Inhalte von Formularen können an einen Angreifer übermittelt werden. Selbst wenn der Link zu vertrauenswürdigen Seiten führt, ist man vor Datenklau nicht gefeit. Cross-Site- und Cross-Frame-Scripting heißen die Angriffstechniken, die zunehmend Verbreitung finden. Wie sie funktionieren und wie man sich davor schützen kann, erklärt der Artikel.
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.
Cross-Site-Scripting (XSS) ist eine der größten Plagen, mit denen Webmaster zu kämpfen haben. Der neue Standard "Content Security Policy" soll endlich Abhilfe schaffen.
Wie schwer ist es, einen Hotelsafe zu knacken? heise Security hat es spontan ausprobiert – mit einem überraschenden Ergebnis.
Die Weboberfläche zur Verwaltung von ProLiant- und Integrity-Servern enthält eine kritische Sicherheitslücke.
Eine Lücke, viele Updates: Adobe hat ein kritisches Sicherheitsloch gestopft und neue Flash- und Air-Versionen für sämtliche Plattformen veröffentlicht.
Am Juni-Patchday hat Microsoft zahlreihe Lücken in Windows, Internet Explorer und Office geschlossen. Eine Rechteausweitungslücke, für die bereits ein Exploit im Netz kursiert, hat die Redmonder Softwareschmiede dabei jedoch offenbar ausgelassen.