Heim

Cross-Site Scripting

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 werden. Aus diesem vertrauenswürdigen Kontext kann dann ein Angriff gestartet werden.

Ziel ist es meist, an sensible Daten des Benutzers um beispielsweise seine Benutzerkonten zu übernehmen (Identitätsdiebstahl).

Eine spezielle Anwendung des XSS ist das Cross-Site Tracing. Entgegen der Namensähnlichkeit sind aber das Cross-Site Cooking und die Cross-Site Request Forgery sowie deren Anwendungen wie etwa die Cross-Site Authentication keine Formen von Cross-Site Scripting.

Inhaltsverzeichnis

Terminologie

Die Bezeichnung „Cross-Site“ bezieht sich darauf, dass der Angriff zwischen verschiedenen Aufrufen einer Seite stattfindet, in der Regel jedoch nicht, dass unterschiedliche Websites beteiligt wären. Meist werden für diese Angriffsart aufgrund ihrer weiten Verbreitung Script-Sprachen – insbesondere JavaScript – genutzt: daher „Scripting“.

Cross-Site Scripting wird manchmal auch „CSS“ abgekürzt, hat jedoch nichts mit Cascading Style Sheets zu tun, für die diese Abkürzung deutlich gängiger ist. Um Verwechslungen zu vermeiden, sollte daher die Abkürzung XSS benutzt werden. Dabei wird das X im Englischen als Abkürzung für Kreuz (= Cross) verstanden.

Funktionsweise

Bei Cross-Site Scripting handelt es sich um eine Art der HTML Injection. Cross-Site Scripting tritt dann auf, wenn eine Webanwendung Daten annimmt, die von einem Nutzer stammen und diese Daten dann an einen Browser weitersendet, ohne den Inhalt zu überprüfen. Damit ist es einem Angreifer möglich auch Skripte indirekt an den Browser des Opfers zu senden und damit Schadcode auf der Seite des Klienten auszuführen.

Ein klassisches Beispiel für Cross-Site Scripting ist die Übergabe von Parametern an ein serverseitiges Skript, das eine dynamische Webseite erzeugt. Dies kann etwa das Eingabeformular einer Webseite sein, wie in Webshops, Foren, Blogs und Wikis üblich. Die eingegebenen Daten werden auf der Webseite wieder als Seiteninhalt ausgegeben, wenn die Seite von Benutzern aufgerufen wird. So ist es möglich, manipulierte Daten an alle Benutzer zu senden, sofern das Serverskript dies nicht verhindert. Diese Daten sind oft Code einer clientseitigen Skriptsprache (meist JavaScript).

Häufige Szenarien eines Angriffs sind das Entführen von Benutzer-Sessions, Website Defacements, das Einstellen von negativen Inhalten, Phishing-Angriffe und die Übernahme der Kontrolle des Benutzerbrowsers.

Besonders gefährlich wird dies, wenn die Webseite, auf der der Schadcode untergebracht wurde, im lokalen Browser mit besonderen Sicherheitsrechten (Privilegien) ausgestattet ist. Der Schadcode kann dann in Abhängigkeit von der Mächtigkeit der Skriptsprache verschiedene Dinge tun, die mit den Rechten des lokalen Benutzers möglich sind. 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.

In der Regel wird XSS etwa in Foren breit gestreut und nicht zielgerichtet an ausgewähle Personen gerichtet. Dies ist jedoch ebenfalls möglich. Neben dem klassischen XSS im Webbrowser, interpretieren häufig auch E-Mail-Programme Scriptcode, was einen Angriff per E-Mail ermöglicht. Dazu schiebt der Angreifer dem Opfer ein von ihm präpariertes HTML-Dokument unter, das per E-Mail verschickt wird. Oder der Angreifer lässt dem Opfer einen Hyperlink zukommen, der auf eine vom Angreifer präparierte Webseite weist oder selbst den Schadcode enthält. Häufig werden dazu auch Kurz-URLs, URL-Spoofing-Techniken und andere Kodierungsverfahren eingesetzt, um den Link zu verschleiern oder vertrauenswürdig erscheinen zu lassen.

Angriffsarten

Es gibt drei grundlegende Arten[1] von Cross-Site-Scripting-Angriffen: Reflektive, Persistente und DOM-basierte. Diese werden im Folgenden erläutert.

In den Beispielen wird zur Anschauung der einfache JavaScript-Code alert("XSS") verwendet, der mithilfe des script-Elements in ein HTML-Dokument eingebunden wird:

<script>alert("XSS");</script>

Dieser JavaScript-Code beschreibt zwar nur einen harmlosen Warnhinweis-Dialog mit dem Text „XSS“. Doch auf gleiche Weise kann auch jeder andere JavaScript-Code eingeschleust werden.

Nicht-Persistent oder Reflektiv

Beim nicht-persistenten (non-persistent) oder reflektiven (reflected) Cross-Site Scripting handelt es sich um einen Angriff bei dem eine Benutzereingabe direkt vom Server wieder zurück gesendet wird. Enthält diese Eingabe Skriptcode, der vom Browser des Benutzers anschließend interpretiert wird, kann dort Schadcode ausgeführt werden.

Hierbei wird der Umstand ausgenutzt, dass dynamisch generierte Webseiten ihren Inhalt oft über URL (HTTP-GET-Methode) oder Formulare (HTTP-GET- oder HTTP-POST-Methode) übergebene Eingabewerte anpassen. Nicht-persistent heißt dieser Typ, da der Schadcode nur temporär bei der jeweiligen Generierung der Webseite eingeschleust wird, nicht aber gespeichert. Ruft man die Seite danach ohne die manipulierte URL oder das manipulierte Formular auf, ist der Schadcode nicht mehr enthalten.


Beispiel:

Eine Suchfunktion soll das Durchsuchen sämtlicher Dokumente einer Website ermöglichen. Dabei wird auf der Ergebnisseite der Suchbegriff nochmals gesondert angezeigt („reflektiert“). Der Funktion kann der Suchbegriff entweder per URL-Argument oder über ein Formular übergeben werden. Eine solche Anfrage sieht damit etwa so aus: http://example.com/?suche=Suchbegriff

Die übergebenen Suchbegriffe werden nun von einer serverseitigen Webapplikation ungeprüft auf der Ergebnisseite wieder ausgegeben:

<p>Sie suchten nach: Suchbegriff</p>

Würde nun hier folgender Suchbgriff verwendet: <script>alert("XSS")</script>
würde dann folgender HTML-Code erzeugt:

<p>Sie suchten nach: <script>alert("XSS")</script></p>

Nach dem gleichen Prinzip kann auch über manipulierte Formulare oder Formulareingaben Schadcode eingeschleust werden. Dies ist schwieriger, da hierbei das Opfer zuerst auf eine Webseite mit manipuliertem Formular gelockt werden muss, das das Opfer dann auch nutzen muss.

Persistent oder Beständig

Persistentes (persistent) oder beständiges (stored) Cross-Site Scripting unterscheidet sich vom reflektiven XSS prinzipiell nur dadurch, dass der Schadcode auf dem Webserver gespeichert wird, wodurch er bei jeder Anfrage ausgeliefert wird. Dies ist bei jeder Webanwendung möglich, die Benutzereingaben serverseitig speichert und diese später wieder ausliefert, solange keine Prüfung der Benutzereingaben bzw. eine geeignete Kodierung der Ausgabe stattfindet.


Beispiel:

Eine Webseite bietet ein Gästebuch, in dem Besucher Nachrichten oder Grüße hinterlassen können. Die eingetragenen Daten werden serverseitig in einer Datenbank gespeichert und bei jedem Aufruf wieder ausgegeben.

Wird nun hier als Nachricht Folgendes eingegeben:

Eine wirklich sehr informative Website!<script>alert("XSS")</script>

Würde diese bei jedem Aufruf ausgeliefert und das Skript vom Browser des Benutzers ausgeführt.

DOM-Basiert oder Lokal

Diese Art des Angriffs wird DOM-basiertes (Dom Injection) oder lokales (local) Cross-Site Scripting genannt.[2] Im Gegensatz zu den oben genannten gängigen XSS-Varianten, ist hier die Webapplikation auf dem Server gar nicht beteiligt. Somit sind auch an sich statische HTML-Seiten mit JavaScript-Unterstützung anfällig für diesen Angriff. Der Schadcode wird direkt an ein clientseitiges Skript zur Ausführung übergeben. Dies kann beispielsweise ein JavaScript sein, das einen URL-Argumentwert zur Ausgabe von Daten verwendet ohne diesen ausreichend zu prüfen. Ein solcher Angriff bedarf des gezielten Aufrufs einer kompromittierten URL.

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


Beispiel:

Eine clientseitige Skriptsprache wie etwa JavaScript liest ein Argumentwert aus der URL aus: http://example.com/foobar.html?arg=Argumentwert

Und fügt diesen nach folgendem Schema ungeprüft in das HTML-Dokument ein:

<p>Sie haben an die URL diesen String angehängt: Argumentwert<p>

Wird nun die aufrufende URL folgendermaßen manipuliert: http://example.com/foobar.html?arg=<script>alert("XSS")</script> würde der durch das serverseitige Skript erzeugte HTML-Code wie folgt aussehen:

<p>Sie haben an die URL diesen String angehängt: <script>alert("XSS")</script><p>

Somit würde obiges Skript im Kontext der aufrufenden Seite ausgeführt werden.

Anmerkung: Dieses einfache Beispiel funktioniert in Firefox nicht ohne weiteres, da dieser die Zeichen einer URL in einem Link implizit kodiert. Es sind aber DOM-Injections bekannt, für die auch Firefox anfällig ist.[2]

Schutz

Schutzmaßnahmen für Webseitenbetreiber

Um durch eine Webanwendung keine Basis für XSS-Angriffe zu bieten, müssen alle eingehenden Eingabewerte als unsicher betrachtet und vor der weiteren Verarbeitung auf der Serverseite geprüft werden.[3] 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[4] es gibt. Besser ist es daher, die „guten“ Eingaben exakt zu definieren (Weiße Liste) und nur solche Eingaben zuzulassen. Dieses Verfahren zählt ganz allgemein zu den Best Practices der Programmierung und sollte wo immer möglich angewandt werden, um unerwartetes Programmverhalten zu verhindern. Allerdings ist es je nach Anwendung nicht immer ohne weiteres in der Praxis umzusetzen, besonders wenn die erlaubten Eingabewerte sehr zahlreich sind.

Eine DOM-Injection zu verhindern ist weit weniger einfach, da Benutzereingaben nicht serverseitig geprüft werden können. Da dieser Angriff unter Umgehung des Servers stattfindet, muss die Gültigkeitsprüfung für Eingabedaten auf Klientenseite im Browser erfolgen, was allerdings wiederum leicht manipulierbar ist.

Um eine Ausgabe in abzusichern (insbesondere bei reflektivem und persistentem XSS), ist es nötig die HTML-Metazeichen durch entsprechende Zeichenreferenzen zu ersetzen, damit sie als normale Zeichen und nicht als Metazeichen behandelt werden. Erfolgt die Ausgabe als Teil von URLs, dann muss die URL-Kodierung auf die Eingabewerte angewendet werden. Bei der Ausgabe in JavaScript-Code müssen die Zeichen mit eine vorangestellten Schrägstrich „\“ maskiert werden. Dabei ist zu beachten, dass bei diesen drei Kontexten (HTML, URL, JavaScript) unterschiedliche Zeichen eine Metafunktion haben (zum Beispiel ist „\“ für HTML kein Metazeichen), es muss also immer eine an das Ausgabemedium angepasste Kodierung verwendet werden.

Die meisten Programmier- sowie Skriptsprachen verfügen über vordefinierte Funktionen zur Ersetzung der Metazeichen. Diese sollten eigenen Verfahren vorgezogen werden, da selbstentwickelte Inhaltsprüfungen weniger gut getestet und ausgereift sind. Darüber hinaus reicht es nicht aus, nur bestimmte Metazeichen zu ersetzen, denn es sind auch Angriffe bekannt, die beispielsweise die HTML-Tag-Klammern nicht erfordern.[5]


Beispiel in Java:

/* regular expression that 
   * tests for the existence of malicious characters 
   * and replaces them with a space. */
 
  final String filterPattern="[<>{}\\[\\];\\&]";
  String inputStr = s.replaceAll(filterPattern," ");

Beispiel in PHP:

<?php
  $boesercode = '<script>alert("XSS");</script>';
  echo 'Sie haben ' . htmlspecialchars($boesercode,ENT_QUOTES) . ' eingegeben';
 
  //Ausgabe: Sie haben &lt;script&gt;alert(&quot;XSS&quot;);&lt;/script&gt; eingegeben
?>


Beispiel in Perl:

#!/usr/bin/perl
use HTML::Entities;
 
my $boesercode = '<script>alert("XSS");</script>';
print 'Sie haben ' . HTML::Entities::encode($boesercode) . ' eingegeben';
 
#Ausgabe: Sie haben &lt;script&gt;alert(&#39;XSS&#39;);&lt;/script&gt; eingegeben

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

Schutzmaßnahmen für Webseitennutzer

Durch Ausschalten der JavaScript-Unterstützung (Active Scripting) im Browser kann man sich gegen clientseitige XSS-Angriffe schützen. Allerdings bieten einige Browser weitere Angriffsvektoren. Dies gilt allerdings nur für „echtes“ XSS, also solches, welches mit JavaScript arbeitet. Wenn nur HTML-Injection (z. B. mit <IFRAME .../>) verwendet wird, dann hilft das Abschalten von Active Scripting im Browser nicht.

Für einige Browser gibt es auch Erweiterungen, mit denen gezielt mögliche XSS-Angriffe erkannt und verhindert werden.

Siehe auch

Quellen

  1. Christiane Rütten, Tobias Glemser: Sicherheit von Webanwendungen Heise-Security, 2006. geprüft 18. Mai 2008
  2. a b Amit Klein: DOM Based Cross Site Scripting or XSS of the Third Kind Web Application Security Consortium, 2005. geprüft 18. Mai 2008.
  3. OWASP-Projekt: CLASP Security Principles: Input Validation (englisch), geprüft 19. Mai 2008
  4. ha.ckers.org: XSS (Cross Site Scripting) Cheat Sheet (englisch)
  5. OWASP-Projekt: Cross Site Scripting (englisch), geprüft 19. Mai 2008