entwickler.com

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

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.

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.

Carsten Eilers

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

• About Security #149: Schwachstellensuche: Zustandsinformationen (1)
• About Security #150: Schwachstellensuche: Zustandsinformationen (2)
• About Security #151: Schwachstellensuche: Cookie Poisoning
• About Security #152: Schwachstellensuche: Contra Cookie Poisoning
• About Security #153: Schwachstellensuche: URL Jumping
• About Security #154: Schwachstellensuche: Der Referer Header
• About Security #155: Schwachstellensuche: Session Hijacking
• About Security #156: Schwachstellensuche: Session Hijacking verhindern
• About Security #157: Schwachstellensuche: Session Fixation