entwickler.com

Bei der Beschreibung der Schwachstellen-Suche in Webanwendungen und im Besonderen bei der Suche nach möglichen zustandsbasierten Angriffen, geht es in dieser Folge um das URL-Jumping. Beim URL-Jumping verlässt ein Angreifer die vorgesehene Reihenfolge der besuchten Seiten und nutzt Funktionen, die eigentlich für ihn zu dem Zeitpunkt noch gar nicht zugänglich sein sollten.

Ursache des Problems ist die bereits in About Security #149 erwähnte Zustandslosigkeit von HTTP. Für die folgenden Erklärungen wird des Öfteren ein Beispiel benötigt, das hier einmal zentral definiert wird.

Beispiel: Ein Webshop

Die zu untersuchende Webanwendung soll ein Webshop sein. Ein normaler Besuch läuft für einen neuen Kunden dann folgendermaßen ab:

1. Durchsuchen des Katalogs nach interessanten Artikeln
   http://www.shop.example/katalog.cgi
2. Auswählen eines Artikels, d.h. Hinzufügen eines Artikels zum Warenkorb
   http://www.shop.example/hinzufuegen.cgi
3. ggf. Suche nach weiteren Artikeln, die ebenfalls dem Warenkorb hinzugefügt werden
4. Prüfen der Bestellung
   http://www.shop.example/bestellen.cgi
5. Eingeben der persönlichen Daten, z.B. der Lieferadresse
   http://www.shop.example/anmelden.cgi
6. Eingeben der Zahlungsinformationen
   http://www.shop.example/zahlen.cgi
7. Abschließen der Bestellung
   http://www.shop.example/abschluss.cgi

Kann ein Angreifer vom Eingeben der persönlichen Daten in Schritt 5 direkt zum Abschluss der Bestellung in Schritt 7 springen, erhält er seine Bestellung evtl., ohne dafür zahlen zu müssen.

Schritt 4d: URL-Jumping

Dieses Beispiel beschreibt nur einen von vielen möglichen Fällen, bei denen das Überspringen von Schritten unerwünschte Folgen hat. Weitere Beispiele sind z.B. das Einloggen in eine Webmail-Anwendung vor dem Lesen einer E-Mail oder das Anmelden bei einem Forum vor dem Veröffentlichen einer Nachricht. Beim URL-Jumping sucht der Angreifer nach einer Abfolge von URLs, die in einer bestimmten Reihenfolge durchlaufen werden müssen, und versucht dann, diese Reihenfolge zu umgehen.

Suche nach Schwachstellen

Der erste Schritt beim Suchen nach einer URL-Jumping-Schwachstelle besteht darin, sich einen Überblick über die zu besuchenden Ressourcen und deren Reihenfolge zu verschaffen. Die im ersten Schritt gesammelten Informationen, insbesondere die dabei aufgebaute Sitemap (siehe About Security #144), liefert dafür die ersten Ansatzpunkte. Gibt es Folgen von Seiten oder Funktionen, die in einer bestimmten Reihenfolge aufgesucht werden müssen?

Wird eine verdächtige Folge gefunden, wird sie zuerst wie ein normaler Benutzer durchlaufen. Dabei werden außer der Reihenfolge der besuchten Seiten auch die übergebenen Parameter protokolliert. Danach wird von dieser Reihenfolge abgewichen: Die verschiedenen Seiten werden gezielt außerhalb der normalen Reihenfolge aufgerufen und das Ergebnis geprüft. Gibt es aufschlussreiche Fehlermeldungen (z.B. "Bitte erst die Benutzerdaten eingeben!") oder sind bestimmte Seiten nicht erreichbar? Sollte es keine Fehlermeldungen geben und alle Seiten sind in beliebiger Reihenfolge aufrufbar, kann das zwei Gründe haben: Entweder die Reihenfolge ist für die Benutzung der Webanwendung entgegen dem ersten Anschein doch bedeutungslos, dann sind entsprechende Angriffe zwecklos. Oder die Reihenfolge ist von Bedeutung, wird aber von der Webanwendung nicht geprüft, geschweige denn erzwungen. In diesem Fall muss ein entsprechender Schutz nachgerüstet werden. Wie das funktioniert, erfahren Sie ab der nächsten Folge.

Ein Angriff

Im Folgenden wird davon ausgegangen, dass die Reihenfolge, in der die Seiten aufgerufen werden, für die Webanwendung von Bedeutung ist und das Einhalten dieser Reihenfolge auch geprüft wird. Eine Möglichkeit, um URL-Jumping zu verhindern, besteht darin, die Adresse der zuvor tatsächlich besuchten Seite mit der Adresse der Seite zu vergleichen, die im Ablauf hätte besucht werden müssen. Im Beispiel würde also beim Aufruf von abschluss.cgi geprüft, ob der Benutzer davor auf zahlen.cgi war, und dort würde geprüft, ob er von anmelden.cgi kommt usw..

Um die zuvor besuchte Seite zu ermitteln, gibt es drei Möglichkeiten:

1. Die Adresse der jeweiligen Seite oder eine entsprechende ID wird in einem versteckten Formularfeld oder einem URL-Parameter gespeichert.
2. Die Adresse der jeweiligen Seite oder eine entsprechende ID wird in einem Cookie gespeichert.
3. Die Adresse, von der der Benutzer kommen sollte, wird mit dem Wert des REFERER-Felds des HTTP-Headers verglichen.

Das und wie versteckte Formularfelder und URL-Parameter manipuliert werden können, wurde bereits in About Security #149 und #150 beschrieben. Das dort Geschriebene gilt hier entsprechend. Dasselbe gilt für in Cookies gespeicherte Daten, wie in About Security #151 und #152 beschrieben. Der einzige Unterschied zwischen dem ersten und zweiten Ansatz ist der: Cookies können nicht direkt im (normalen) Browser manipuliert werden und machen den Angriff minimal schwieriger.

Wie sicher die Nutzung des REFERER-Headers ist und welche Gegenmaßnahmen es gegen solche Angriffe gibt, erfahren Sie in der nächsten Folge von About Security.

Carsten Eilers