Skip to content

XSS-Suche, Teil 2: So erkennnen Sie Schutzfunktionen

Nachdem Sie alle möglicherweise für XSS anfälligen Parameter der Webanwendung ermittelt haben, kann die Suche nach XSS-Schwachstellen eigentlich los gehen. Es sind nur noch ein paar Vorbemerkungen nötig.

Schutzfunktionen erkennen

Die einfachste Möglichkeit, eine Prüfung oder Filterung zu erkennen, besteht in einer Änderung des Testmusters. Ein einfacher Teststring wie das vorgeschlagene IIIXSSTestParameternameIII in der Ausgabe zeigt nur, das der entsprechende Parameter in der erzeugten Webseite erscheint. Selbst bei einer Prüfung und/oder Filterung sollte diese Zeichenkette unversehrt in der Ausgabe erscheinen, da sie nichts verdächtiges bzw. (potentiell) gefährliches enthält.

Als nächster Test wird das Testmuster um potentiell gefährliche Zeichen, also insbesondere <, >, / und :, erweitert. Das könnte zum Beispiel folgendes Testmuster ergeben: III<XSSTestParametername>III.

Wie reagiert die Webanwendung auf diese Zeichen? Im Prinzip gibt es nur folgende Möglichkeiten:

Die Zeichenkette erscheint unverändert in der Ausgabe.
Dann gibt es evtl. doch keine Prüfung/Filterung.
Als nächstes muss das Einschleusen funktionsfähigen Codes ausprobiert werden, evtl. reagiert die Schutzfunktion nur auf tatsächlich existierende oder auch nur auf potentiell gefährliche Tags wie zum Beispiel <script>-Tags. Achten Sie beim Test aber darauf, wo der Parameter ausgegeben wird. Sehr oft muss der Testcode an den Ausgabeort angepasst werden, damit er vom Browser auch wirklich ausgeführt wird. Wird der eingeschleuste Code, zum Beispiel zum Öffnen einer Alertbox, wirklich ausgeführt? Herzlichen Glückwunsch, Sie haben eine XSS-Schwachstelle gefunden!
Das Testmuster erscheint gar nicht in der Ausgabe.
Dann wird die Eingabe auf die potentiell gefährlichen Zeichen geprüft und beim Erkennen eines oder mehrerer solcher Zeichen komplett verworfen.
In diesem Fall ist zu prüfen, ob die Schutzfunktion sich austricksen lässt, zum Beispiel durch eine andere Kodierung der gefährlichen Zeichen.
Die potentiell gefährlichen Zeichen fehlen ganz oder teilweise in der Ausgabe.
Auch in diesem Fall sind weitere Tests nötig: Können die vorhandenen Schutzfunktionen durch eine andere Kodierung oder die Verwendung anderer Tags umgangen werden?
Die potentiell gefährlichen Zeichen wurden umgewandelt.
Es reicht zum Beispiel oft aus, < und > in ihre HTML-Entities &lt; und &gt; umzuwandeln, um möglicherweise eingeschleusten Schadcode unbrauchbar zu machen. Auch in diesem Fall sind weitere Tests nötig: Was passiert, wenn die benötigten Zeichen anders kodiert werden? Evtl. prüft die Webanwendung nur auf ASCII-Zeichen und kann durch URL- oder UTF-kodierte Zeichen ausgetrickst werden.

Liegt der Quelltext der Webanwendung vor, ist ein Blick auf die entsprechenden Funktionen zum Prüfen und Filtern der Eingaben hilfreich. Ansonsten bleibt nur das systematische Ausprobieren aller Möglichkeiten zum Umgehen der Schutzfunktionen.

Das XSS Filter Evasion Cheat Sheet von OWASP und das HTML5 Security Cheatsheet enthalten eine umfangreiche Sammlung von Möglichkeiten, Filter zu umgehen.

Systematisches Ausprobieren aller Möglichkeiten klingt nach einer stupiden Arbeit, und für sowas ist ja eigentlich ein Computer prädestiniert. In der Tat ist das eine Aufgabe, für die ein Scanner gut geeignet ist. Zum Beispiel das kostenlose OWASP Xenotix XSS Exploit Framework oder der Scanner der kostenpflichtigen Version der Burp Suite.

Nicht einmal testen, sondern drei mal

Bei der Suche nach Schwachstellen, bei denen Benutzereingaben manipuliert werden, reicht es nicht, nur die von der Webanwendung verwendeten Methoden zur Übertragung der Parameter zu testen. Jeder Parameter kann über drei Methoden übertragen werden: Über die GET- oder die POST-Methode oder als Cookie. Es kommt immer wieder vor, das die verwendete Methode in der Webanwendung nicht oder falsch beachtet wird. Wird der eine Parameter geprüft, aber ein anderer verwendet, kann der Angreifer seinen Schadcode an der Schutzfunktion vorbei schmuggeln.

Dazu ein Beispiel: In PHP gibt es verschiedene Arrays für die über GET, POST und Cookies übertragenen Parameter sowie das Array $_REQUEST, in das der Reihe nach erst die GET-, dann die POST- und danach die Cookie-Parameter geschrieben werden (sofern die Standard-Reihenfolge nicht umkonfiguriert wurde.

Wird der Wert aus dem GET-Array für die Ausgabe verwendet, aber der Wert im REQUEST-Array geprüft, kann ein Angreifer seinen Schadcode über einen GET-Parameter einschleusen und durch einen gleichnamigen POST-Parameter tarnen: $_GET["name"] enthält den XSS-Code, $_POST["name"] einen harmlosen Wert. Im zusammengeführten Array $_REQUEST überschreibt der POST-Parameter den gleichnamigen GET-Parameter und die Anwendung prüft den harmlosen Wert.

Wie schon erwähnt führen je nachdem, wo ein Parameter ausgegeben wird, verschiedene Ansätze zum Ziel, der Ausführung des eingeschleusten Codes. Und um die geht es in der nächsten Folge.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : XSS-Suche, Teil 3: Der Kontext bestimmt den Test

Vorschau anzeigen
Nachdem Sie alle möglicherweise für XSS anfälligen Parameter der Webanwendung ermittelt und eine möglicherweise vorhandene Schutzfunktion erkannt haben, kann die Suche nach XSS-Schwachstellen los gehen. Je nachdem, wo e