CSRF: Cross-Site-Request-Forgery-Attack erklärt

Cross-Site-Request-Forgery (CSRF oder XSRF abgekürzt) ist eine Angriffsmethode, die meist für Internetbetrug genutzt wird. Kriminelle übernehmen eine vom Nutzer autorisierte Session (Session Riding) und können so schadhafte Aktionen durchführen. Dies geschieht über HTTP-Request.

Nehmen wir an, ein Nutzer hat sich auf einer Onlineplattform angemeldet. Nach dem Log-in bleibt der Anwender für die Dauer der Session (diese Zeitspanne wird ganz unterschiedlich gehandhabt) angemeldet – ohne sein Passwort erneut eingeben zu müssen. Diesen Umstand macht sich der Internetkriminelle zunutze: Angemeldete Nutzer können schließlich meist mehr und auch tiefer greifende Aktionen durchführen als nicht anmeldete User.

Das Prinzip von CSRF kurz erklärt: Während der Nutzer also in dem Portal angemeldet ist, besucht er auch eine andere und zwar vom Hacker erstellte Website. Dort führt der Nutzer irgendeine Aktion aus, beispielsweise das Drücken eines Buttons. Der Angreifer sendet infolgedessen einen HTTP-Request an das vom User genutzte Portal und führt unter der Identität des Users eine schädliche Aktion aus, da die Session noch aktiv ist. Um dies erreichen zu können, muss der Angreifer nur den korrekten HTTP-Request kennen, welcher sich aber relativ leicht auslesen lässt.

Der Server des Portals erkennt den HTTP-Request als korrekt formuliert an und merkt über die entsprechenden Cookies auch, dass der Nutzer (bzw. dessen Browser) noch eingeloggt ist. Der Server führt die Aktion aus und der Nutzer registriert möglicherweise nicht, dass gerade in seinem Namen eine Handlung durchgeführt wurde.

Die CSRF-Attacke ist deswegen erfolgreich, weil der empfangende Server nicht überprüft, woher die Anfrage überhaupt kommt. Es ist also nicht bekannt, ob der HTTP-Request durch die eigene Website erzeugt wurde oder eine fremde Quelle hat. Der Angreifer macht sich dabei eine Schwäche des Browsers zunutze: Dieser leitet die Anfragen weiter, ohne die Konsequenzen zu beurteilen.

Drei Varianten von CSRF-Attacken werden besonders häufig durchgeführt: Am populärsten dürfte das Unterschieben einer URL sein. Diese wird auf einer externen Website oder in einer E-Mail versteckt. Der Aufruf dieser URL löst den HTTP-Request aus. Prinzipiell ist so eine URL für den Nutzer durchaus sichtbar, sofern er denn genau darauf achtet. Mithilfe von Social Engeneering und URL-Spoofing kann der Ursprung der URL aber verschleiert werden.

Es gibt auch Anknüpfungspunkte zum sogenannten Cross-Site-Scripting (XSS): Statt eine eigene schadhafte Website aufzubauen, manipulieren einige Hacker eine bereits bestehende Website über XSS, die dann ohne Wissen des Betreibers für kriminelle Aktionen genutzt wird. In der Regel wird bei dieser Attacke einer Website JavaScript untergeschoben, das dann wiederum die CSRF-Attacke durchführt.

Auch wenn Angreifer es schaffen, Schad-Software auf dem Computer des Opfers unterzubringen, ist eine Cross-Site-Request-Forgery-Attacke möglich. So kann der Angreifer den Browser direkt anweisen, die HTTP-Anfrage zu senden. Wer allerdings Viren oder Malware auf dem Client unterbringen kann, hat noch zahlreiche weitere Angriffsmöglichkeiten.

In unserem Beispiel für CSRF beziehen wir uns auf das Onlinebanking, weil dadurch am besten die potenzielle Tragweite der Angriffstechnik deutlich wird. Ein Nutzer meldet sich also in seinem Banking-Account an. Dort gibt es ein spezifisches Formular zur Überweisung. Füllt man das Formular aus und drückt den Bestätigungs-Button, wird ein spezifischer HTTP-Request an den Server gesendet und die Überweisung wird durchgeführt. Der Angreifer weiß allerdings genau, wie das Formular und der HTTP-Request aufgebaut sind, und kann beides nachbauen. Als Informationen werden dann die Kontodaten des Betrügers sowie ein von ihm festgelegter Betrag eingefügt.

Der Hacker kann dann eine Website aufsetzen (oder eine E-Mail versenden), die für den Beispielnutzer von Interesse ist. Dort wird zum scheinbar harmlosen Klicken eines Links aufgefordert, was aber den gefälschten HTTP-Request aktiviert. Dieser wird dann an die Bank gesendet, die die vom Hacker gewünschte Aktion durchführt. Die Session ist noch aktiv und die Anfrage korrekt: Es gibt für den Server keinen Grund, die Handlung nicht auszuführen. Das Geld wird demnach einfach überwiesen. Der Nutzer merkt das erst, wenn er später irgendwann seinen Kontostand überprüft.

Weitere Angriffsszenarien:

• Social-Media: Im Namen von angemeldeten Nutzern werden Kommentare gepostet oder Likes verteilt.
• Website-Administration: Hat ein Opfer Zugang zum Backend, können ohne dessen Wissen neue Benutzer angelegt oder die komplette Website kann gelöscht werden.
• Onlineshopping: Ohne Wissen des zahlenden Nutzers, kauft ein Angreifer Waren in einem Onlineshop.

Auf Nutzerseite heißt es, Vorsicht walten zu lassen: Wer nicht auf fragwürdigen Websites surft oder bedenkliche E-Mails öffnet, kann eigentlich kaum Opfer eines solchen Angriffs werden. Zum Schutz vor CSRF sollte man auch aktive Sessions bei sicherheitsrelevanten Portalen beenden, bevor man Websites aufsucht, deren Reputation man nicht einschätzen kann.

Außerdem muss der Nutzer sicherstellen, dass sein Gerät (PC, Notebook, Smartphone usw.) frei von Schad-Software ist. Agiert eine Anwendung im Hintergrund und späht den Nutzer aus, wird es deutlich schwerer, CSRF zu verhindern. Ist der Client bereits infiziert, sind aber auch noch ganz andere Angriffstechniken möglich.

Aber auch Website-Betreiber können ihre Besucher schützen: Die Angreifer können Cross-Site-Forgery-Attacken durchführen, weil sie den genauen Aufbau der entsprechenden Formulare und HTTP-Requests kennen. Bringt man einen Zufallsfaktor ins Spiel, muss der Hacker in der Regel kapitulieren. Die Website kann ein einmaliges Token erstellen (quasi eine willkürliche Zeichenfolge) und dieses zu einem Teil der des HTTP-Requests machen. Erhält der Server eine Anfrage, die gar kein oder ein (nicht mehr) gültiges Token enthält, wird die Anfrage dann automatisch abgelehnt.

Beim Onlinebanking ist auch grundsätzlich eine Zwei-Faktor-Authentisierung vorgesehen: Bevor Nutzer eine Überweisung durchführen können, müssen sie eine TAN eingeben, die nicht über die Website zur Verfügung gestellt wird. Diese Technik schützt nicht nur vor CSRF, sondern auch vor anderen Angriffen. Selbst wenn der Angreifer die Zugangsdaten ausgespäht hätte, könnte er keine Überweisung durchführen, solange der zweite Faktor fehlt.

Theoretisch besteht schon durch den Referrer Header ein Schutz. Dieser Teil der HTTP-Anfrage gibt an, wo die Anfrage herkommt. Websites könnten somit alle fremden Quellen ausfiltern. Der Referrer Header hat sich aber in der Vergangenheit als unzuverlässig herausgestellt. Erweiterungen im Browser – wie zum Beispiel Adblocker – verändern oder löschen den Referrer Header. Nutzer mit solchen Konfigurationen könnten das Angebot der Website dann nicht mehr nutzen.

Eine Maßnahme, die keinen endgültigen Schutz bietet, aber zumindest eine Hürde für Angreifer darstellt, besteht darin, Sessions nur begrenzt laufen zu lassen. Was das betrifft, wägen Websitebetreiber Risiko und Benutzerfreundlichkeit gegeneinander ab. Die Portale von Banken beispielsweise brechen die Session bereits nach wenigen Minuten ohne Benutzereingabe ab. Andere Websites (wie zum Beispiel viele Social-Media-Portale), die mit weniger sensiblen Daten arbeiten, lassen Sessions allerdings auch über Tage aktiv. Sobald der Nutzer nicht mehr in dem Portal angemeldet ist, kann eine CSRF-Attacke nicht mehr wirken.