Cross-Site Request Forgery

Eine Cross-Site Request Forgery (auf Deutsch etwa „Seiten-übergreifende Aufruf-Manipulation“, meist CSRF oder XSRF abgekürzt) ist ein Angriff auf ein Computersystem, bei dem der Angreifer eine Transaktion in einer Webanwendung durchführt. Dies geschieht nicht direkt, sondern der Angreifer bedient sich dazu eines Opfers, das bei einer Webanwendung bereits angemeldet sein muss. Dem Webbrowser des Opfers wird ohne dessen Wissen ein arglistiger HTTP-Request untergeschoben. Der Angreifer wählt den Request so, dass bei dessen Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.

Das Sicherheitsproblem ist auf die Statuslosigkeit des HTTP-Protokolls zurückzuführen, da nach einmaliger Authentifizierung der Browser implizit jedes Mal seine Sitzungsdaten an den Server sendet. Trifft die Webanwendung keine Maßnahmen gegen CSRF-Angriffe, ist die Webanwendung verwundbar.

Während sich CSRF auf jede Form der Datenänderung mittels HTTP-Requests bezieht, ist bei Session-Riding die Manipulation der Daten mittels einer gültigen Session des Opfers gemeint. Session-Riding ist ein Spezialfall von CSRF mit der Bedingung, dass die Session-ID mittels Basic/Digest Authentication oder Cookie transportiert wird.

Im Artikel hier wird vereinfacht vom Cookie gesprochen, wenn eine Session (insbesondere eine Session-ID) gemeint ist. CSRF tritt jedoch nicht nur bei (HTTP-)Form-basierter, sondern auch bei Basic- bzw. Digest-Authentifizierung auf.

Geschichte

Bereits im Oktober 1988 veröffentlichte Norm Hardy ein Dokument, in dem er den Sachverhalt von Vertrauen auf Anwendungsebene diskutierte und diesen „a Confused Deputy“ (dt. etwa: „einen verwirrten Stellvertreter“) nannte. Im Jahr 2000 wurde auf der Sicherheits-Mailingliste Bugtraq erörtert, wie ZOPE von einem confused-deputy-Problem betroffen war, welches man heute als CSRF-Sicherheitslücke einstufen würde. Später dann, im Jahr 2001, veröffentlichte Peter Watkins auf bugtraq einen Beitrag zur Diskussion „The Dangers of Allowing Users to Post Images“ (dt. etwa: „Gefahren, wenn Anwender Bilder einbinden dürfen“), mit der er den Ausdruck Cross-Site Request Forgery prägte.

Beispiele

Ein recht harmloses Beispiel einer CSRF wäre eine URL auf die Abmelden-Funktion von Wikipedia

http://de.wikipedia.org/w/index.php?title=Spezial:Userlogout

Wird einem in der Wikipedia angemeldeten Benutzer dieser Link untergeschoben, sodass sein Browser diesen Request absetzt, wird er ohne eigenes Zutun von der Wikipedia abgemeldet, vorausgesetzt die Webanwendung auf Wikipedia hat keinen Schutz gegen CSRF-Angriffe.

Schwerwiegender wäre eine solche URL bei der Benutzerverwaltung einer nicht öffentlichen Seite. Zum Beispiel könnte der Angreifer mit

http://www.example.com/user.php?action=new_user&name=badboy&password=geheim

einen neuen Benutzer anlegen und sich somit unberechtigten Zugang zu der entsprechenden Webanwendung verschaffen, wenn er es schafft, dem Administrator der Webanwendung diesen HTTP-Request unterzuschieben und dieser angemeldet ist.

Angriffsvektoren

Damit der Angreifer eine Cross-Site Request Forgery ausführen kann, muss er den Webbrowser des Opfers dazu bringen, einen oder mehrere vom Angreifer manipulierte HTTP-Requests auszuführen. Hierzu gibt es mehrere Angriffsvektoren:

Cross-Site Scripting

Hierbei übermittelt der Angreifer zunächst selber entsprechend gewählten HTML-Code an die Webanwendung. Diese speichert den Code und fügt ihn späteren Anfragen anderer Benutzer an, ohne den HTML-Code zu maskieren. Diese Schwachstelle bezeichnet man als Cross-Site Scripting (XSS). Die Cross-Site Request Forgery besteht darin, wie der Webbrowser des Opfers mit dem HTML-Code umgeht. Dieser besteht beispielsweise aus einem img-Tag, mit dem ein Webbrowser angewiesen wird, automatisch eine Grafik für die Seite nachzuladen. Anstelle der URL, unter der die Grafik zu finden ist, wird der Angreifer hier den manipulierten Request einfügen. Sobald der Webbrowser des Opfers die URL aufruft, wird also der manipulierte Request abgesendet und von der Webanwendung so verarbeitet, als wäre er vom Opfer autorisiert. Anstelle eines img-Tags mit einer manipulierten URL kann der Angreifer auch JavaScript-Code in die Seite einbauen. Damit ließe sich auch die unten beschriebene Abwehrmaßnahme eines Shared-Secrets unterwandern.

Unterschieben der URL

Neben der Möglichkeit, den Aufruf der manipulierten URL über Cross-Site-Scripting zu automatisieren, kann der Angreifer auch aus einer Reihe anderer Möglichkeiten wählen, um das Opfer zum Aufruf einer manipulierten URL zu bewegen. Dabei wird die URL üblicherweise entweder per E-Mail an das Opfer übermittelt oder findet sich auf einer Webseite, die nicht einmal zwingend Teil der betroffenen Webanwendung sein muss. Im Gegensatz zum Cross-Site-Scripting muss der Angreifer aber (je nach Gutgläubigkeit des Opfers mehr oder weniger) Überredungskunst einsetzen, um das Opfer zum Aufruf der URL zu bewegen, was auch als Social Hacking bezeichnet wird. Dabei kann die manipulierte URL zu Täuschungszwecken entweder mittels URL-Spoofing verfremdet sein oder durch einen Kurz-URL-Dienst verschleiert werden. Wählt der Angreifer E-Mail als Medium, kann er mittels Mail-Spoofing zusätzlich um das Vertrauen des Opfers werben, indem er sich etwa als Administrator der betroffenen Webanwendung ausgibt.

Möchte der Angreifer verhindern, dass das Opfer nach dem erfolgreichen Angriff von dem Vorgang erfährt, kann der Angreifer auch zunächst die URL einer eigenen Seite angeben, die beispielsweise ein lustiges Bild enthält. In diese Seite wird der Angreifer dann aber einen versteckten Frame einbauen, in dem dann der Aufruf der manipulierten URL stattfindet. Nutzt das Opfer ein E-Mail-Programm, das ungefragt auch in der E-Mail eingebettete Bilder über den Webbrowser aus dem Internet nachlädt, könnte man hiermit diesen Angriffsvektor auch ausnutzen, ohne auf die aktive Mitwirkung des Opfers angewiesen zu sein.

All diese Methoden setzen aber voraus, dass der Benutzer bereits bei der betroffenen Webanwendung angemeldet ist, seine Zugangsdaten in einem Cookie gespeichert hat oder der Aufforderung nachkommt, sich gegenüber der Webanwendung zu authentisieren. Während letzterer Fall bei einem gesunden Maß an Menschenverstand eher unwahrscheinlich ist, stellt insbesondere die erste Situation für den Angreifer eine reelle Chance auf Erfolg dar, da viele Webanwendungen dem Anwender anbieten, seine Zugangsdaten aus Komfortgründen in dessen Webbrowser zu speichern.

Local Exploit

Hat der Angreifer die Kontrolle über den Computer des Opfers durch eine dort laufende Schadsoftware, kann er ebenfalls eine CSRF ausführen. Dazu muss die Schadsoftware lediglich den Browser anweisen, die manipulierte URL aufzurufen, was mit geringen Programmierkenntnissen keine Hürde darstellt. Die Schwierigkeit bei diesem Angriff besteht vielmehr darin, eine für den Angriff geeignete Schadsoftware auf dem Computer des Opfers zu installieren. Da dies aber nicht spezifisch für den hier geschilderten Angriff ist, soll hier auch nicht näher darauf eingegangen werden.

Abwehrmaßnahmen

Je nach Angriffsvektor ist entweder der Benutzer für clientseitige oder der Betreiber der Webanwendung für serverseitige Abwehrmaßnahmen gegen eine Cross-Site Request Forgery zuständig.

Serverseitig

Jede Transaktion der Webapplikation muss mit einer weiteren – dem Browser und der Webanwendung – gemeinsamen geheimen Information versehen werden. In der Regel ist dies ein sogenanntes Page-Token, meistens eine Zahl oder eine Zeichenkette, die in einem Hidden-Field auf der Seite eingebunden ist. Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field nicht auslesbar für den Angreifer. Insbesondere kann eine persistente XSS-Schwachstelle den CSRF-Schutz aushebeln, nicht jedoch eine reflexive.

Clientseitig

Der Benutzer einer Webanwendung muss sicherstellen, dass sein Computer frei von Schadsoftware ist. Gegen ein Programm, das im Kontext des Benutzers auf dem Client ausgeführt wird, ist jede serverseitige Abwehrmaßnahme zwecklos.

Die folgenden Hinweise sind unnötig, wenn die serverseitige Sicherheit gewährleistet ist. Da der Anwender dies aber nie sicherstellen kann, werden sie der Vollständigkeit halber mit aufgeführt:

Viele Webanwendungen, wie zum Beispiel auch die Wikipedia, bieten ihren Nutzern die Möglichkeit, dauerhaft angemeldet zu sein. Technisch wird hierbei in der Regel die in einem Cookie gespeicherte Session-ID am Ende einer Sitzung nicht gelöscht. Diese Komfortfunktion vergrößert aber auch die Angriffsfläche, da der Angreifer nicht mehr einen Zeitpunkt abpassen muss, zu dem sein Opfer an der Webanwendung angemeldet ist. Der Verzicht auf diese Funktion erhöht folglich die Hürden, die der Angreifer nehmen muss.

Möchte der Angreifer eine XSS-Lücke ausnutzen, um die Sicherheitsvorkehrung eines Shared-Secrets zu umgehen, ist er darauf angewiesen, dass im Browser des Opfers JavaScript oder JScript aktiviert sind. Das Deaktivieren kann folglich ebenfalls die Angriffsfläche verringern; in der Regel nutzen aber viele Webanwendungen diese clientseitigen Scriptsprachen selber, so dass dies nicht möglich ist.

Unzulängliche Abwehrmaßnahmen

Einige Maßnahmen zur Unterbindung von CSRF-Angriffen reichen nicht aus, um einen hinreichenden Schutz zu gewährleisten. Sie sind bestenfalls dazu geeignet, die Hürde für den Angreifer etwas höher zu hängen und wiegen den Betreiber einer Webanwendung schlimmstenfalls in Scheinsicherheit.

Nur HTTP-Post akzeptieren

Ein CSRF-Angriff kann nicht dadurch verhindert werden, dass Requests, die zu einer Veränderung von Daten führen, nur per HTTP-POST akzeptiert werden. Auch per HTTP-POST kann ohne weiteres ein gefälschter Request abgesetzt werden. Dazu erstellt der Angreifer eine Seite, auf die er das Opfer lockt. Dort wird der manipulierte Request entweder mittels einer clientseitigen Skriptsprache wie zum Beispiel JavaScript erzeugt oder der Angreifer bringt das Opfer dazu, auf einen Button oder ein Bild zu klicken, wodurch der Request abgesetzt wird. Wählt der Angreifer als Ziel (target-Parameter) des Formulars einen unsichtbaren Frame oder Inlineframe, sind auch hier die Chancen gering, dass das Opfer den Angriff bemerkt.

HTTP-Referrer-Prüfung

Die Prüfung des HTTP-Referrer-Headers bietet zwar einen gewissen Schutz vor reinen CSRF-Angriffen, da gefälschte Requests, die von einem Angreifer mittels Täuschung des Opfers auf einer externen Webseite ausgelöst wurden, zum Teil geblockt werden können. Die Webanwendung ist jedoch gut beraten, sich nicht auf den Schutz des Referrers zu verlassen: Viele Browser-Plugins erlauben es aber Requests mit beliebigem Referrer abzusetzen, z.B. das weit verbreitete Adobe Flash^[1] (in etwas älteren Versionen). Außerdem können Benutzer oder auch Proxy-Server aus Datenschutzgründen das Übertragen des Referrers unterbinden oder gezielt einen anderen Wert eintragen, wodurch die Web-Anwendung nicht mehr allen legitimen Anwendern offensteht (false positives). Aus Gründen der Benutzbarkeit einer Webanwendung sollte man grundsätzlich gar nicht den Referrer-Header für HTTP-Request verwenden.

Quellen

• Norman Hardy, The Confused Deputy: (or why capabilities might have been invented), ACM SIGOPS Operating Systems Review, Volume 22, Issue 4 (October 1988)
• RFC 2616: 9.1.1 Safe Methods
• The Cross-site Request Forgery FAQ
• Client Side Trojans
• CSRF - "sea surf"
• Artikel von Sverre Huseby: Client Side Trojans
• Foiling Cross-Site Attacks
• Concerns over the name "Session Riding"

Weblinks

• Heise Developer Channel -- OWASP Top 10 2010
• Security tips for Web developers
• Bundesamt für Sicherheit in der Informationstechnik (BSI): Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen (PDF, 922 KB)
• PHP Security Workbook (PDF, 1 MB)
• Session-Angriffe - eine Analyse (deutsch)
• TecChannel: CSRF-Angriffe auf Router und Webanwendungen (deutsch)

Einzelnachweise

1. ↑ "(...) it's possible to send requests from a Flash object to any URL, with almost any HTTP headers the attacker needs"