Channel Security

In About Security #158 erfuhren Sie, wie einfache Fälle von XSS-Schwachstellen gefunden werden können: Wenn es keinerlei Prüfung der Eingaben gibt, reicht die übliche Alertbox oder auch ein einfaches Testmuster zum Finden der Schwachstellen aus. Öffnet sich die Alertbox bzw. erscheint das Testmuster in der Ausgabe, ist XSS möglich. Schwieriger wird es, wenn die Eingaben auf eingeschleusten Code geprüft und/oder vor der Ausgabe gefiltert werden.

Schutzfunktionen erkennen

Die einfachste Möglichkeit, eine Prüfung oder Filterung zu erkennen, besteht in einer Änderung des Testmusters. Ein Testmuster wie das in About Security #158 vorgeschlagene ##XSS-Test## in der Ausgabe zeigt nur, dass 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. (potenziell) Gefährliches enthält. Trotzdem ist diese Zeichenkette ein guter Ansatz für die Suche nach möglichen XSS-Schwachstellen: Überall, wo sie in der Ausgabe erscheint, könnte HTML- oder Skriptcode eingeschleust werden. Die Parameter, über die das Testmuster erfolgreich eingeschleust wurde, müssen dann genauer untersucht werden.

Als nächster Test wird das Testmuster um potenziell gefährliche Zeichen, also insbesondere <, >, / und :, erweitert. Das könnte z.B. folgendes Testmuster ergeben: ##<XSS-:-Test/>##.

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

1. Die Zeichenkette erscheint unverändert in der Ausgabe.
   Dann gibt es eventuell doch keine Prüfung/Filterung. Als Nächstes muss das Einschleusen funktionsfähigen Codes ausprobiert werden, eventuell reagiert die Schutzfunktion nur auf tatsächlich gefährlichen Code wie z.B. <script>-Tags. Wird eingeschleuster Code, z.B. zum Öffnen einer Alertbox, wirklich ausgeführt? Wird diese Frage mit 'ja' beantwortet, wurde eine XSS-Schwachstelle gefunden.
2. Das Testmuster erscheint gar nicht in der Ausgabe.
   Dann wird die Eingabe auf die potenziell 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, z.B. durch eine andere Kodierung der gefährlichen Zeichen.
3. Die potenziell gefährlichen Zeichen fehlen ganz oder teilweise in der Ausgabe.
   Auch in diesem Fall sind weitere Tests möglich: Können die vorhandenen Schutzfunktionen durch eine andere Kodierung oder die Verwendung anderer Tags umgangen werden?
4. Die potenziell gefährlichen Zeichen wurden umgewandelt.
   Es reicht beispielsweise 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? Eventuell prüft die Webanwendung nur auf ASCII-Zeichen und kann durch URL- oder UTF-kodierte Zeichen ausgetrickst werden.

Liegt der Quelltext der Webanwendung vor, entweder weil es die eigene ist oder weil es sich um Open-Source-Software handelt, 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 Cheat Sheet enthält 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. So gibt es z.B. auch das Cheat Sheet als XML-Datei zur Nutzung durch Tools wie das aus dem CAL9000-Projekt des Open Web Application Security Project (OWASP). Um diese und viele andere Tools wird es in zukünftigen Folgen von About Security gehen, vorerst geht es primär um die manuelle Suche.

Nicht einmal testen, sondern dreimal

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, dass 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 vorbeischmugglen. Dazu ein Beispiel:

In PHP gibt es verschiedene Arrays für die über GET, POST und Cookies übertragenen Parameter sowie das Array , in das der Reihe nach erst die GET-, dann die POST- und danach die Cookie-Parameter geschrieben werden. Wird das GET-Array verwendet, aber das REQUEST-Array geprüft, kann ein Angreifer seinen Schadcode über einen GET-Parameter einschleusen und durch einen gleichnamigen POST-Parameter tarnen: ["name"] enthält den XSS-Code, ["name"] einen harmlosen Wert. Im zusammengeführten Array überschreibt der POST-Parameter den gleichnamigen GET-Parameter und die Anwendung prüft den harmlosen Wert.

Einige Möglichkeiten, komplizierteren XSS-Schwachstellen auf die Spur zu kommen, werden in der nächsten Folge vorgestellt.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Schwachstellensuche – III. Angriffe über vom Benutzer gelieferte Daten: XSS"

• About Security #158: Schwachstellensuche: Einfaches XSS
• About Security #159: Schwachstellensuche: XSS trotz Filter
• About Security #160: Schwachstellensuche: XSS finden
• About Security #161: Schwachstellensuche: XSS verhindern
• About Security #162: Schwachstellensuche: Persistentes XSS (1)
• About Security #163: Schwachstellensuche: Persistentes XSS (2)
• About Security #164: Schwachstellensuche: Persistentes XSS (3)
• About Security #165: Schwachstellensuche: DOM-basiertes XSS