Session-Riding

Eine Cross-Site Request Forgery (zu deutsch etwa „Site-übergreifende Aufruf-Manipulation“, meist XSRF oder CSRF abgekürzt) ist ein Angriff auf ein Computersystem, bei dem der Angreifer unberechtigt Daten in einer Webanwendung verändert. Er bedient sich dazu eines Opfers, das ein berechtigter Benutzer der Webanwendung sein muss. Mit technischen Maßnahmen oder zwischenmenschlicher Überredungskunst wird hierzu aus dem Webbrowser des Opfers ohne dessen Wissen und Einverständnis ein kompromittierter HTTP-Request an die Webanwendung abgesetzt. Der Angreifer wählt den Request so, dass bei dessen Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.

Abgrenzung

Anders als bei anderen Angriffen auf Webanwendungen findet dieser Angriff ausschließlich im Webbrowser des Opfers statt; der Angreifer ist an der Interaktion mit der Webanwendung weder aktiv (wie z.B. bei einem Man-In-The-Middle-Angriff) noch passiv (wie z.B. beim Belauschen der Datenübertragung) beteiligt. Darum eignet sich dieser Angriff unmittelbar auch nur zum Manipulieren von Daten in der Webanwendung, nicht aber zum Aus- oder Mitlesen von Daten. Erst durch die Manipulation von Zugangsdaten kann der Angreifer sich gegebenenfalls in einem zweiten Schritt Zugriff auf die Webanwendung verschaffen, falls das Ausspähen von Daten sein Ziel ist.

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. Es kann sich dabei aber auch um eine Basic/Digest Authentication handeln, da dies genauso für CSRF anfällig ist.

Historie

Bereits im Oktober 1988 veröffentlichte Norm Hardy ein Dokument, in dem er auf den Sachverhalt von Vertrauen auf Anwendungsebene diskutierte und nannte diesen „a Confused Deputy“ (dt. etwa: „ein verwirrter Stellvertreter“). 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 hochladen dürfen“), mit der er den Ausdruck Cross-Site Request Forgery prägte.

Rechtliches

In Deutschland ist die rechtswidrige Datenveränderung (§ 303a StGB) und Computersabotage (§ 303b StGB) ebenso wie das Ausspähen von Daten, die gegen unberechtigten Zugang besonders gesichert sind, (§ 202a StGB) eine Straftat.

Beispiele

Ein recht harmloses Beispiel einer CSRF wäre ein Link 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.

Schwerwiegender wäre ein solcher Link auf eine Funktion der Benutzerverwaltung einer 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.

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, wie TinyURL 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 zweite 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

Jeder Request an die Webapplikation, der einen schreibenden Zugriff auf die Daten vornimmt, muss mit einem Shared-Secret versehen sein. Dieses wird in die URL des Links bzw. in ein Hidden-Field des Formulars auf der Seite eingebunden, auf der der reguläre Benutzer diese Aktion auslösen darf. Serverseitig wird das Shared-Secret in der Session des Benutzers gespeichert und beim nächsten Request verworfen, unabhängig davon, ob der Benutzer die dazugehörige Aktion ausgelöst hat oder nicht. Requests, die eine Änderung der Daten anfordern aber kein gültiges Shared-Secret beinhalten, werden (ggf. mit einem entsprechenden Hinweis an den Benutzer) verworfen. Moderne Web-Application-Frameworks bieten hierfür eine entsprechende Unterstützung an. Daneben muss der Betreiber sicherstellen, dass seine Webanwendung keine Möglichkeit zum Cross-Site Scripting bietet. Ohne diese Sicherung ist die obenstehende Maßnahme wirkungslos, da der Angreifer über manipuliertes JavaScript innerhalb der Seite wieder Kenntnis von dem Shared-Secret erlangen kann. Webanwendungen, die kein clientseitiges Scripting, wie z.B. JavaScript, voraussetzen, werden im Allgemeinen als sicherer betrachtet, da der Anwender in seinem Browser das Scripting ohne Funktionalitätseinbußen abschalten kann.

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 z.B. 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 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 von Request-Headers, wie z. B. des Referrers, bietet ebenfalls keinen hinreichenden Schutz vor CSRF-Angriffen, auch nicht in Kombination mit einem erzwungenen HTTP-Post-Request für datenverändernde Anfragen. Aus Datenschutzgründen kann der Benutzer oder auch ein Proxy-Server das Übertragen des Referrer-Headers unterbinden, wodurch die Web-Anwendung nicht mehr allen legitimen Anwendern offensteht. Zudem kann ein CSRF-Angriff auch durch Cross-Site-Scripting auf derselben Seite eingeleitet werden. In diesem Fall trägt das Referrer-Feld einen korrekten Wert und der Angriff wird erfolgreich ausgeführt.

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
• Session Riding (PDF, 200 kB)
• Concerns over the name "Session Riding"

Weblinks

• 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)

Bitte beachte den Hinweis zu Rechtsthemen!