Dipl.-Inform. Carsten Eilers

Persistentes XSS funktioniert fast genauso wie reflektiertes XSS, nur das der Angreifer nun seinen JavaScript-Schadcode zum Beispiel in einem Kommentar unter einem Blogeintrag, in einem Eintrag im Gästebuch oder einer der vielen Möglichkeiten des "User Generated Content" im Web 2.0 speichert. Immer vorausgesetzt natürlich, dort gibt es eine entsprechende Schwachstelle und der XSS-Code kann eingeschleust werden.

Immer, wenn der manipulierte Eintrag aufgerufen wird, wird der darin gespeicherte JavaScript-Schadcode des Angreifers im Webbrowser des Benutzers im Kontext der betroffenen Webanwendung ausgeführt.

Dabei ist es egal, ob ein Benutzer gezielt auf diese Seite gelockt wird, sie während des normalen Besuchs der Website erreicht oder zum Beispiel von einer Suchmaschine kommt. Auch ist es prinzipiell egal, ob die Seite von einem normalen Benutzer aus dem Internet heraus ausgerufen wird, oder ob ein Administrator sie aus dem Backend der Webanwendung heraus öffnet. Jedenfalls, so lange die Seite im Browser gerendert wird. Öffnet der Admin sie zum Beispiel in einem Editor-Fenster des Backends, wird der enthaltene Code natürlich nicht ausgeführt, sondern dargestellt.

Den prinzipiellen Ablauf des Angriffs zeigt folgendes Bild:

Abb. 1: Persistentes XSS

Persistentes XSS betrifft im allgemeinen nicht nur eine einzelne Seite einer Website, sondern alle der betroffenen Kategorie. Ist zum Beispiel eine Kommentarfunktion für XSS anfällig, betrifft das alle darüber eingegebenen Kommentare und nicht nur die eines bestimmten Eintrags oder was auch immer.

Dementsprechend kann ein Angreifer seinen Code auch auf mehreren Seiten eingeben. Oder eingeben lassen. Zum Beispiel vom Schadcode selbst: Der könnte zum Beispiel eine Funktion enthalten, über die er sich selbst bei jedem Aufruf im Namen des jeweiligen Benutzers als neuer Kommentar unter einem weiteren Artikel einträgt. Und schon haben wir sich selbst vervielfältigen Code und damit etwas, was man allgemein als (Computer-)Wurm bezeichnet. Oder genauer: Einen XSS- oder Web-Wurm.

Eigentlich geht es ja erst später um die möglichen Angriffe, XSS-Würmer beschreibe ich aber schon an dieser Stelle. Aus dem einfachen Grund, dass das einfache Verbreiten als Wurm die eine Sache ist (um die es hier geht). Denn was die Würmer sonst noch alles anstellen können, ist ganz einfach alles, was sich auch ganz allgemein über XSS erreichen lässt. Und das wird später beschrieben.

Ein Beispiel für einen XSS-Wurm: Der MySpace-Wurm Samy

Als Beispiel für einen XSS-Wurm verwende ich mal wieder mein Lieblingsbeispiel: Samy, den MySpace-Wurm. Das hat viele Gründe. Zum Beispiel war er der erste seiner Art. Auch ist er sehr gut dokumentiert. Er enthält keine weiteren Funktionen außer der Verbreitungsroutine und lenkt damit nicht vom wesentlichen ab. Und er hat den großen Vorteil, ein echter "In the Wild" entdeckter Wurm zu sein. Und sogar ein äußerst erfolgreicher.

Das Konzept eines Web-Wurms kann man natürlich an jeder Menge konstruierter Beispiele eben so gut beschreiben wie am Beispiel eines echten Wurms. Aber die bekommen immer schnell das "Das funktioniert ja nur unter Laborbedingungen"-Etikett angeheftet. Samy ist der erste und beste Beweis dafür, dass Web-Würmer möglich sind und Schaden anrichten können.

Entwickelt wurde Samy (der Wurm) von Samy Kamkar, der für diesen Angriff unter anderen mit 3 Jahren Computer-Verbot bestraft wurde, danach aber noch mehrmals erfolgreich als Sicherheitsforscher auf neue Gefahren aufmerksam gemacht hat.

Samy Kamkar war 2005 der Meinung, zu wenig Freunde auf MySpace zu haben. Samy (der Wurm) sollte das ändern. Und tat es so erfolgreich, dass MySpace seine Website abschalten musste, um die Freundesflut zu stoppen.

Ausgehend von Samy Kamkars Profilseite verbreitete sich der Wurm über eine persistente XSS-Schwachstelle in die Profilseiten der Besucher eines befallenen Profils. Über einen XMLHttpRequest wurde Samy zum Freund und 'Hero' des Besuchers gemacht und der Wurmcode in dessen Profilseite integriert. Innerhalb von 20 Stunden hatte Samy Kamkar mehr als 1 Million Freunde und Samy (der Wurm) entsprechend viele Profile verseucht. MySpace musste den Betrieb vorübergehend komplett einstellen, um den Wurm zu stoppen und alle befallenen Seiten zu reinigen.

Wie Samy (der Wurm) funktioniert, erfahren Sie in der nächsten Folge.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Cross-Site Scripting im Überblick, Teil 1: Reflektiertes XSS

Cross-Site Scripting im Überblick, Teil 2: Persistentes XSS

Cross-Site Scripting im Überblick, Teil 3: Der MySpace-Wurm Samy

Angriffe über Cross-Site Scripting: Der Sourcecode des MySpace-Wurms Samy

Cross-Site Scripting im Überblick, Teil 4: DOM-basiertes XSS

Cross-Site Scripting im Überblick, Teil 5: Resident XSS

XSS-Angriffe, Teil 1: Informationen einschleusen

XSS-Angriffe, Teil 2: Cookies und Tastendrücke ausspähen

XSS-Angriffe, Teil 3: Zugangsdaten ausspähen

XSS-Angriffe, Teil 4: Ein Blick in die History, und dann auf ins LAN!

XSS-Angriffe, Teil 5: Ein Portscan (nicht nur) im LAN

XSS-Angriffe, Teil 6: Ein verbesserter Portscanner

XSS-Angriffe, Teil 7: Hindernisse beim JavaScript-Portscan beseitigen

XSS-Angriffe, Teil 8: Ein Portscan mit WebSockets oder Cross-Origin Requests

XSS-Angriffe, Teil 9: Der Router im Visier

XSS-Angriffe, Teil 10: Weitere Angriffe auf den Router

XSS-Angriffe, Teil 11: Unerwünschtes Firmware-Update für den Router

XSS-Angriffe, Teil 12: Browser-basierte Botnets

XSS-Angriffe, Teil 13: Fortgeschrittene Angriffe

XSS-Angriffe, Teil 14: Das Browser Exploitation Framework BeEF