Channel Security

Cross-Site-Scripting-Schwachstellen wurden bereits in About Security #14 und #15 vorgestellt. Allgemein gesagt, wird beim Cross-Site Scripting (XSS) das Vertrauen des Benutzers bzw. seines Browsers in eine Webseite ausgenutzt: "Von einer vertrauenswürdigen Webseite mitgelieferter JavaScript-Code ist vertrauenswürdig". Diese so genannte Same Origin Policy erlaubt dem JavaScript-Code, die Seite zu ändern und vom eigenen Server Daten nachzuladen. Nach der Beschreibung der Grundlagen in About Security #14 und #15 geht es jetzt weiter ins Detail.

Unheimliche Begegnung der dritten Art

Während früher nur zwei Arten von XSS (reflektiertes und persistentes) bekannt waren, ist durch die intelligenteren Clients des Web 2.0 eine dritte hinzugekommen: DOM-basiertes oder lokales XSS. Damit werden jetzt folgende drei Arten von XSS unterschieden:

• DOM-basiertes oder lokales XSS
  Der Schadcode wird durch eine Schwachstelle im clientseitigen Skriptcode eingeschleust, d.h. über eine Funktion innerhalb der betroffenen Seite, die übergebene Daten ungeprüft ausgibt.
  Für den Angriff ist der Aufruf eines präparierten URL s nötig, der den Schadcode enthält.
• Reflektiertes XSS
  Der Schadcode wird an den Webserver gesendet und von diesem an den Client zurückgegeben.
  Auch für diesen Angriff ist der Aufruf eines präparierten URLs oder das Absenden eines präparierten Formulars nötig, die den Schadcode enthalten.
• Persistentes XSS (JavaScript-Injection)
  Der Schadcode wird auf dem Webserver gespeichert, z.B. in einem Gästebucheintrag, und danach bei jedem Aufruf der betroffenen Seite ausgeliefert.
  Während bei den anderen beiden Arten der Angriff nur durch den dafür präparierte URL bzw. das dafür präparierte Formular ausgelöst wird, erfolgt er hier bei jedem Aufruf der Seite mit dem eingeschleusten Schadcode. Wie der Benutzer diese Seite erreicht, ist egal.

Reflektiertes und am Rande auch persistentes XSS wurden bereits in About Security #14 und #15 beschrieben, im Folgenden geht es daher speziell um DOM-basiertes XSS. Diese Schwachstellen wurden erstmals 2005 von Amit Klein in seinem Paper "DOM Based Cross Site Scripting or XSS of the Third Kind" beschrieben.

DOM-basiertes XSS unterscheidet sich in einem Punkt von reflektiertem oder persistentem XSS: Der Schadcode ist zu keiner Zeit Bestandteil der vom Server gelieferten "rohen" HTML-Seite – der Server, ein IDS/IPS oder eine Web Application Firewall können ihn darin also nicht erkennen.

Eine Webseite ist immer dann für DOM-basiertes XSS anfällig, wenn sie Daten aus vom Angreifer kontrollierbaren Objekten wie z.B. document.location, document.URL oder document.referrer ohne Prüfung auf eingeschleusten Code verwendet. Ein einfaches Beispiel (nach Amit Klein, "DOM Based Cross Site Scripting or XSS of the Third Kind"):

Eine Webseite enthält den folgenden Code:

Hallo

<script>
 var pos=document.URL.indexOf("name")+5;
 document.write(document.URL.substring(pos,document.URL.length));
</script>

Willkommen auf dieser Seite ...

Beim Aufruf dieser Seite wird der Benutzer mit seinem Namen begrüßt, z.B. beim Aufruf von

http://www.beispiel.example/index.html?name=Anton

Der übliche XSS-Test mit

http://www.beispiel.example/index.html?name=<script>alert('XSS')</script>

führt dagegen zum Öffnen der Alertbox.

Dieses Beispiel funktioniert nicht, wenn der Webbrowser den URL selbstständig URL-kodiert, wie es z.B. Mozilla und Firefox tun. Dadurch werden die < und > zu %3C bzw. %3E, was die spätere Codeausführung verhindert. Die Umkodierung verhindert aber keine Angriffe, die nicht auf < und > angewiesen sind.

Der Angriff ist möglich, weil der Browser beim Aufruf des präparierten URLs einen HTTP-Request an www.beispiel.example sendet, die statische HTML-Seite mit obigen Code darin empfängt und dann beginnt, die HTML-Daten in das DOM zu parsen. Das DOM enthält das Objekt document, das die Eigenschaft URL besitzt, in der der URL der aktuellen Seite steht. Erreicht der Parser den JavaScript-Code, führt er ihn aus und ändert entsprechenden den enthaltenen Anweisungen die Seite. Der Code kopiert einen Teil des Inhalts von document.URL in die HTML-Seite. Im Beispiel also "Anton" – oder eben den Schadcode "<script>alert('XSS')</script>". Das Ergebnis sieht im zweiten Fall folgendermaßen aus:

Hallo

<script>alert('XSS')</script>

Willkommen auf dieser Seite ...

Die fertiggestellte HTML-Seite wird dann geparst – und dabei der eingeschleuste Skriptcode ausgeführt.

In der nächsten Folge werden u.a. die Tarnung des Schadcodes und mögliche Gegenmaßnahmen behandelt.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Sichere Webanwendungen – Cross-Site Scripting"

• About Security #14: Cross-Site Scripting
• About Security #15: Cross-Site Scripting verhindern
• About Security #129: Cross-Site Scripting, reloaded
• About Security #130: DOM-basiertes XSS abwehren
• About Security #131: XSS-Angriffe (1)
• About Security #132: XSS-Angriffe (2)
• About Security #133: XSS-Angriffe (3): JavaScript Ping & Co.
• About Security #134: XSS-Angriffe (4): JavaScript Portscan
• About Security #135: XSS-Angriffe (5): JavaScript Portscan vorbereiten
• About Security #136: XSS-Angriffe (6): DSL-Router ausspähen
• About Security #137: XSS-Angriffe (7): Weitere Ziele