Donnerstag, 29. Dezember 2011


Topthema

Donnerstag, 1. Mai 2008 | Topthema

About Security #153: Schwachstellensuche: URL Jumping

(Link zum Artikel: http://www.entwickler.de/business-technology/kolumnen/042985)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

URL Jumping ist ein weiterer zustandsbasierter Angriff auf Webanwendungen. 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.

N E U ! Security aktuell
T�glich aktuelle Security-Infos!

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?

About Security: Die komplette Serie

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.

Wenn Sie Fragen oder Themenvorschl�ge haben, k�nnen Sie diese gerne an die angegebene E-Mail-Adresse senden oder im Security-Forum einbringen!

Carsten Eilers

About Security � �bersicht zum aktuellen Thema "Schwachstellensuche � II. Zustandsbasierte Angriffe"

Kommentare

Folgende Links könnten Sie auch interessieren