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 < und > 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.
Trackbacks
Dipl.-Inform. Carsten Eilers am : XSS-Suche, Teil 3: Der Kontext bestimmt den Test
Vorschau anzeigen