Benutzer:Raf-dat/Penetration Testing/XSS

Unter XSS (Cross-Side Scripting) versteht man die Methode, durch eine Schwachstelle im PHP-Script, eigenen HTML-Code zu injizieren.

Stored XSS

Ein gutes Beispiel, welches immer noch häufig anzutreffen ist, ist die Filterfunktion bei einem Gästebuch.

Der normale Benutzer schreibt vielleicht in das Feld:
Schöne Homepage! Besonders die Galerie gefällt mir.

Im Quelltext sieht das dann folgendermaßen aus:

<p>
Schöne Homepage! Besonders die Galerie gefällt mir.
</p>

Ohne, dass jetzt die fehlende Umwandlung der Umlaute beachtet wird, sieht das ganz akzeptabel aus.

Doch was, wenn der Besucher nun eingibt:
<script type="text/javascript">alert("XSS");</script>

Wenn der Input nicht gefiltert wird, wird das normal in den Quelltext geschrieben:

<p>
<script type="text/javascript">alert("XSS");</script>
</p>

Ein mögliches Ergebniss eines XSS-Angriffes

Und anstelle eines netten Textes bekommt jeder Besucher eine Anzeigebox mit dem Text "XSS" zu sehen.

Das alleine wäre höchstens nervig, aber mit dieser Methode lassen sich auch gefährlichere Funktionen ausführen: Die gesamte JavaScript-Palette steht dem Angreifer zu Verfügung. Man könnte z. B. mittels document.cookie die Cookies des Opfers setzen oder auslesen und an einen externen Server leiten (dazu später mehr), das Design der ganzen Seite ruinieren, das Opfer auf eine andere Seite weiterleiten, um Phishing zu betreiben... Die Anzahl der Möglichkeiten ist nur begrenzt durch die Fantasie des Angreifers.

Anmerkung: Man könnte natürlich alle HTML-Elemente in einem solchen Angriff verwenden, aber JavaScript ist in diesem Fall die mit Abstand mächtigste Waffe.

Reflected XSS

Diese Art von XSS ist ebenfalls häufig anzutreffen. Der Unterschied zu Stored XSS ist, dass Reflected XSS nicht für alle Benutzer sichtbar ist. Nehmen wir als Beispiel eine Suchfunktion, wie sie auf jeder 08/15-Homepage anzutreffen ist. Oft wird der Suchstring mit der GET-Methode versendet (suche.php?q=foobar). Es kann aber auch vorkommen, dass der String mit der Methode POST versendet wird. In diesem Fall eignen sich Firefox-Addons wie Tamper Data, um die übertragenen Daten noch abzufangen und zu verändern.

Die Möglichkeit, die Lücke zu exploiten läuft im Grunde genommen gleich ab, wie beim Stored XSS. Nur, was macht man mit einem Alert, wenn er niemanden (ausser sich selbst) nerven kann? Die Lösung lautet: Man verschickt den Link mit der ausgenutzten Lücke. Die URL sieht für den Empfänger harmlos aus, aber der Schadcode wird beim öffnen der Seite trotzdem ausgeführt. Mit der Methode POST funktioniert es (leider) nicht. Diese ist für den Angreifer ziemlich nutzlos.

Falls das potentielle Opfer auf die Idee kommen sollte, die URL doch genauer unter die Lupe zu nehmen, bevor es sie aufruft, kann man mit Intet-Diensten (Beispiel-Links werden von MediaWiki geblockt) die URL kürzen oder die Buchstaben durch ihre ASCII-Äquivalente ersetzen (A wird zu %41, [Space] wird zu %20).

Wofür man einen verschickten Link benutzen kann, dazu komme ich später noch.

Erweitertes XSS

Es soll vorkommen, dass man einen halbherzigen Schutz einbaut. Zum Beispiel werden nur bestimmte Zeichen gefiltert. In diesem Fall muss man kreativ sein. Denn man kann - je nach Browser und Version - noch auf viele andere Arten JavaScript-Code ausführen.

Zum Beispiel, wenn man in einem Bild-Container "gefangen" ist. Nehmen wir an, das Grundgerüst ist gegeben: <img src="$string" />. Es kommt nämlich nicht selten vor, dass der String in so einem Gerüst ausgegeben wird. Der Angreifer könnte nun auf die Idee kommen, folgendermassen aus diesem Gerüst auszubrechen:
" /><script>...</script><img src="

Würde Folgendes ergeben:
<img src="" /><script>...</script><img src="" />

Nun hat aber der clevere (?) Webmaster folgende Zeichen gefiltert: <, >, "
Der Angreifer steht mit leeren Händen da. Weil er aber hartnäckig ist, versucht er es auf eine andere Weise:
javascript:alert('XSS')

Das ergibt: <img src="javascript:alert('XSS')" />, was wie eine normale URL geladen wird und unter Umständen den Wünschen des Angreifers gerecht wird.

Dieses Beispiel soll demonstrieren, dass nicht immer der erste Weg funktioniert. Kreativität ist gefragt. Meistens funktionieren sogar mehrere Wege, wenn man lange genug probiert.

Um eine XSS-Lücke effektiv zu nutzen, ist es unumgänglich, JavaScript zu beherrschen. Dazu gibt es auf diesem Wiki einschlägige Literatur, da das nicht der Inhalt dieses Buches ist.

Absicherung gegen XSS

Der Schutz gegen XSS muss im PHP-Script vorgenommen werden. Dort wandelt die Funktion htmlentities() alle Sonderzeichen HTML-konform um. Unter anderem auch Umlaute und Ähnliches, erledigt also schon viele Schritte in einem.

Einige Programmierer sperren die Anfrage, wenn ein gefährliches Zeichen vorkommt oder ignorieren den Text nach einem gefährlichen Zeichen. Meiner Meinung nach sollte man immer htmlentities() verwenden, da die gefährlichen Zeichen zwar umgewandelt werden, aber im Browser doch anständig angezeigt werden.

Beispiele

Eines der berühmtesten Beispiele war der Wurm Samy, der im Jahr 2005 die Webseite MySpace für einige Stunden lahmlegte. Der 19-jährige Samy wollte seine Freundin beeindrucken und entdeckte auf MySpace eine Möglichkeit dazu. Denn man konnte in seinem Profil eigenen HTML-Code eingeben. MySpace war nicht dumm, sie hatten ziemlich alle Möglichkeiten geblockt, JavaScript auszuführen. Doch durch eine Kombination von CSS und JavaScript gelang es Samy, einen Code zu entwickeln, der jeden Besucher seines Profiles automatisch zu seiner Freundeliste hinzufügte und den selben Code auch bei sich selbst einpflanzte. Der Wurm verbreitete sich exponentiell und führte schlussendlich zum Absturz der Server.

Eine technische Dokumentation wäre hier zu umfangreich, aber Samy hat auf seiner Seite eine detaillierte Beschreibung gepostet.

Weiterführende Links

• Wikipedia-Beitrag über XSS
• http://ha.ckers.org/xss.html Sehr umfangreiches Cheat-Sheet mit Strings für Proof of Concept