Montag, 2. Januar 2012


Topthema

Donnerstag, 8. Mai 2008 | Topthema

About Security #154: Schwachstellensuche: Der Referer Header

(Link zum Artikel: http://www.entwickler.de/entwicklerde/kolumnen/043160)
  • Teilen
  • kommentieren
  • empfehlen
  • Bookmark and Share

Auch die Nutzung des Referer Headers sch�tzt die Webanwendung nicht zuverl�ssig vor URL Jumping. Wieso das so ist und wie Sie eine Webanwendung vor solchen Angriffen sch�tzen k�nnen, erfahren Sie in dieser Folge.

Der Referer Header

Ein HTTP-Request f�r eine Seite aus dem in About Security #153 eingef�hrten Beispiel k�nnte folgenderma�en aussehen:

GET /abschluss.cgi HTTP/1.1
Host: www.shop.example
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) [...]
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: de-de
Connection: keep-alive
Referer: http://www.shop.example/zahlen.cgi
Bedeutung der Header-Felder

Die Header-Felder haben folgende Bedeutung: �ber die GET-Methode wird die Seite /abschluss.cgi vom Host www.shop.example angefordert. Der User-Agent, der den Webbrowser des Benutzers identifiziert, ist in diesem Fall uninteressant, ebenso die verschiedenen Accept- und der Connection Header. Von Interesse ist der Referer Header: Von wo wurde auf die angeforderte Seite verwiesen? In diesem Fall ist das
http://www.shop.example/zahlen.cgi

W�re der Benutzer z.B. �ber Google zur angeforderten Seite gekommen, k�nnte der Referer Header wie folgt aussehen:
http://www.google.com/search?client=safari&rls=de-de&
q=Bestellung+abschlie�en&ie=UTF-8&oe=UTF-8

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

Der Referer Header wird vom Webbrowser automatisch gesetzt, ist aber nicht immer vorhanden: Stammt der Link aus den Bookmarks oder wurde er direkt in die Adresszeile eingegeben, gibt es keinen Referer und damit auch keinen entsprechenden Header-Eintrag.

HTTP-Request- und -Response-Header k�nnen Sie sich z.B. beim Web-Sniffer ansehen.

Woher kommst Du?

Wenn man wissen m�chte, ob ein Benutzer vor dem Aufruf einer Seite auf einer bestimmten anderen Seite war, bietet sich auf den ersten Blick die Pr�fung des Referer Headers an: War der Benutzer vor dem Aufruf von abschluss.cgi auf zahlen.cgi, steht im Referer-Header http://www.shop.example/zahlen.cgi, ansonsten etwas anderes oder nichts.

Beim Aufruf einer Seite B, die erst nach der Seite A aufgerufen werden darf, muss also nur der Referer Header gepr�ft werden. Steht darin die vorhergehende Seite A, wird die neue Seite ausgeliefert, ansonsten gibt es eine Fehlermeldung.

Wirklich?

Soweit, so gut. Dieser Ansatz funktioniert so lange, wie der Referer Header den korrekten Wert enth�lt. Das ist aber nicht zwingend der Fall. Manche Browser senden den Referer Header aus Datenschutzgr�nden nicht mit, und auch Proxies k�nnen ihn aus demselben Grund aus dem Request l�schen. Noch kritischer sind Manipulationen durch einen Angreifer. Da der Referer Header vom Webbrowser gesetzt wird, kann er vom Angreifer nicht einfach im Browser oder der herunter geladenen Seite manipuliert werden. W�hrend der �bertragung ist er jedoch ungesch�tzt und kann z.B. in einem Proxy wie Paros manipuliert werden. Au�erdem kann der Angreifer jederzeit einen eigenen Client verwenden, der die Header nach seinen Vorgaben setzt. Im Rahmen von CSRF-Angriffen ist auch die Manipulation der Header �ber Flash (Korrektur) oder XMLHttpRequests bekannt, siehe auch About Security #128.

Der Referer Header ist also ebenfalls keine gute Wahl, wenn die zuvor besuchte Seite ermittelt werden soll.

About Security: Die komplette Serie
URL Jumping verhindern

Um URL Jumping zu verhindern, muss die Reihenfolge der Seitenaufrufe �berpr�ft werden. Dazu muss die jeweils zuvor besuchte Seite gespeichert werden. Wie in About Security #153 und oben zu sehen war, ist der Client daf�r nicht geeignet: Ein Angreifer kann alle dort gespeicherten Informationen mit mehr oder weniger viel Aufwand nach Belieben manipulieren. Daher muss die Information, welche Seite ein Benutzer zuletzt besucht hat, auf dem Server gespeichert werden.

Kann oder soll die zuletzt besuchte Seite nicht auf dem Server gespeichert werden, ist die Pr�fung des Referer Headers die beste der verf�gbaren M�glichkeiten. Der Parameter ist zwar nicht sicherer als die anderen, aber unauff�lliger. Wenn die Webanwendung einen Cookie setzt oder einen Parameter in einem Formular oder der URL �bertr�gt, ist das immer ein Hinweis darauf, dass irgend etwas f�r den Angreifer interessantes damit passiert. Der Referer Header wird jedoch automatisch mit jedem Request mitgeschickt. Ob er von der Webanwendung ausgewertet wird oder nicht, ist f�r den Angreifer nicht direkt ersichtlich. Das ist aber keine Garantie daf�r, dass ein Angreifer die Schutzfunktion nicht trotzdem erkennt und umgeht.

Identifikation des Benutzers

Hier wie auch bei vielen zuvor besprochenen Angriffen m�ssen als Gegenma�ahme Informationen auf dem Server statt auf dem Client gespeichert werden. Das ist relativ einfach zu realisieren: F�r jeden Benutzer werden die entsprechenden Informationen tempor�r im Programm oder auch l�ngerfristig in einer Datei oder Datenbank gespeichert. Das f�hrt zu neuen Fragen: Wie erkennt bzw. unterscheidet man die Benutzer, und ergibt das neue Angriffspunkte? Die Antworten auf diese Fragen erhalten Sie in der n�chsten Folge.

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