Was ist CSRF (Cross-Site-Request-Forgery-Attack)?

Cross-Site-Request-Forgery (CSRF oder XSRF abgekürzt) ist eine An­griffs­me­tho­de, die meist für In­ter­net­be­trug genutzt wird. Kri­mi­nel­le über­neh­men eine vom Nutzer au­to­ri­sier­te Session (Session Riding) und können so schad­haf­te Aktionen durch­füh­ren. Dies geschieht über HTTP-Request.

Nehmen wir an, ein Nutzer hat sich auf einer On­line­platt­form an­ge­mel­det. Nach dem Log-in bleibt der Anwender für die Dauer der Session (diese Zeit­span­ne wird ganz un­ter­schied­lich ge­hand­habt) an­ge­mel­det – ohne sein Passwort erneut eingeben zu müssen. Diesen Umstand macht sich der In­ter­net­kri­mi­nel­le zunutze: An­ge­mel­de­te Nutzer können schließ­lich meist mehr und auch tiefer greifende Aktionen durch­füh­ren als nicht anmeldete User.

Das Prinzip von CSRF kurz erklärt: Während der Nutzer also in dem Portal an­ge­mel­det ist, besucht er auch eine andere und zwar vom Hacker erstellte Website. Dort führt der Nutzer ir­gend­ei­ne Aktion aus, bei­spiels­wei­se das Drücken eines Buttons. Der Angreifer sendet in­fol­ge­des­sen einen HTTP-Request an das vom User genutzte Portal und führt unter der Identität des Users eine schäd­li­che 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 for­mu­liert an und merkt über die ent­spre­chen­den Cookies auch, dass der Nutzer (bzw. dessen Browser) noch ein­ge­loggt ist. Der Server führt die Aktion aus und der Nutzer re­gis­triert mög­li­cher­wei­se nicht, dass gerade in seinem Namen eine Handlung durch­ge­führt wurde.

Die CSRF-Attacke ist deswegen er­folg­reich, weil der emp­fan­gen­de 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 Kon­se­quen­zen zu be­ur­tei­len.

Drei Varianten von CSRF-Attacken werden besonders häufig durch­ge­führt: Am po­pu­lärs­ten dürfte das Un­ter­schie­ben 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. Prin­zi­pi­ell ist so eine URL für den Nutzer durchaus sichtbar, sofern er denn genau darauf achtet. Mithilfe von Social En­ge­nee­ring und URL-Spoofing kann der Ursprung der URL aber ver­schlei­ert werden.

Es gibt auch An­knüp­fungs­punk­te zum so­ge­nann­ten Cross-Site-Scripting (XSS): Statt eine eigene schad­haf­te Website auf­zu­bau­en, ma­ni­pu­lie­ren einige Hacker eine bereits be­stehen­de Website über XSS, die dann ohne Wissen des Be­trei­bers für kri­mi­nel­le Aktionen genutzt wird. In der Regel wird bei dieser Attacke einer Website Ja­va­Script un­ter­ge­scho­ben, das dann wiederum die CSRF-Attacke durch­führt.

Auch wenn Angreifer es schaffen, Schad-Software auf dem Computer des Opfers un­ter­zu­brin­gen, ist eine Cross-Site-Request-Forgery-Attacke möglich. So kann der Angreifer den Browser direkt anweisen, die HTTP-Anfrage zu senden. Wer al­ler­dings Viren oder Malware auf dem Client un­ter­brin­gen kann, hat noch zahl­rei­che weitere An­griffs­mög­lich­kei­ten.

In unserem Beispiel für CSRF beziehen wir uns auf das On­line­ban­king, weil dadurch am besten die po­ten­zi­el­le Tragweite der An­griffs­tech­nik deutlich wird. Ein Nutzer meldet sich also in seinem Banking-Account an. Dort gibt es ein spe­zi­fi­sches Formular zur Über­wei­sung. Füllt man das Formular aus und drückt den Be­stä­ti­gungs-Button, wird ein spe­zi­fi­scher HTTP-Request an den Server gesendet und die Über­wei­sung wird durch­ge­führt. Der Angreifer weiß al­ler­dings genau, wie das Formular und der HTTP-Request aufgebaut sind, und kann beides nachbauen. Als In­for­ma­tio­nen werden dann die Kon­to­da­ten des Betrügers sowie ein von ihm fest­ge­leg­ter Betrag eingefügt.

Der Hacker kann dann eine Website aufsetzen (oder eine E-Mail versenden), die für den Bei­spiel­nut­zer von Interesse ist. Dort wird zum scheinbar harmlosen Klicken eines Links auf­ge­for­dert, was aber den ge­fälsch­ten HTTP-Request aktiviert. Dieser wird dann an die Bank gesendet, die die vom Hacker ge­wünsch­te Aktion durch­führt. Die Session ist noch aktiv und die Anfrage korrekt: Es gibt für den Server keinen Grund, die Handlung nicht aus­zu­füh­ren. Das Geld wird demnach einfach über­wie­sen. Der Nutzer merkt das erst, wenn er später ir­gend­wann seinen Kon­to­stand überprüft.

Weitere An­griffs­sze­na­ri­en:

• Social-Media: Im Namen von an­ge­mel­de­ten Nutzern werden Kom­men­ta­re gepostet oder Likes verteilt.
• Website-Ad­mi­nis­tra­ti­on: Hat ein Opfer Zugang zum Backend, können ohne dessen Wissen neue Benutzer angelegt oder die komplette Website kann gelöscht werden.
• On­line­shop­ping: Ohne Wissen des zahlenden Nutzers, kauft ein Angreifer Waren in einem On­line­shop.

Auf Nut­zer­sei­te heißt es, Vorsicht walten zu lassen: Wer nicht auf frag­wür­di­gen Websites surft oder be­denk­li­che E-Mails öffnet, kann ei­gent­lich kaum Opfer eines solchen Angriffs werden. Zum Schutz vor CSRF sollte man auch aktive Sessions bei si­cher­heits­re­le­van­ten Portalen beenden, bevor man Websites aufsucht, deren Re­pu­ta­ti­on man nicht ein­schät­zen kann.

Außerdem muss der Nutzer si­cher­stel­len, dass sein Gerät (PC, Notebook, Smart­phone usw.) frei von Schad-Software ist. Agiert eine Anwendung im Hin­ter­grund und späht den Nutzer aus, wird es deutlich schwerer, CSRF zu ver­hin­dern. Ist der Client bereits infiziert, sind aber auch noch ganz andere An­griffs­tech­ni­ken möglich.

Aber auch Website-Betreiber können ihre Besucher schützen: Die Angreifer können Cross-Site-Forgery-Attacken durch­füh­ren, weil sie den genauen Aufbau der ent­spre­chen­den Formulare und HTTP-Requests kennen. Bringt man einen Zu­falls­fak­tor ins Spiel, muss der Hacker in der Regel ka­pi­tu­lie­ren. Die Website kann ein ein­ma­li­ges Token erstellen (quasi eine will­kür­li­che Zei­chen­fol­ge) 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 au­to­ma­tisch abgelehnt.

Beim On­line­ban­king ist auch grund­sätz­lich eine Zwei-Faktor-Au­then­ti­sie­rung vor­ge­se­hen: Bevor Nutzer eine Über­wei­sung durch­füh­ren 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 Zu­gangs­da­ten aus­ge­späht hätte, könnte er keine Über­wei­sung durch­füh­ren, solange der zweite Faktor fehlt.

Theo­re­tisch 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 aus­fil­tern. Der Referrer Header hat sich aber in der Ver­gan­gen­heit als un­zu­ver­läs­sig her­aus­ge­stellt. Er­wei­te­run­gen im Browser – wie zum Beispiel Adblocker – verändern oder löschen den Referrer Header. Nutzer mit solchen Kon­fi­gu­ra­tio­nen könnten das Angebot der Website dann nicht mehr nutzen.

Eine Maßnahme, die keinen end­gül­ti­gen Schutz bietet, aber zumindest eine Hürde für Angreifer darstellt, besteht darin, Sessions nur begrenzt laufen zu lassen. Was das betrifft, wägen Web­site­be­trei­ber Risiko und Be­nut­zer­freund­lich­keit ge­gen­ein­an­der ab. Die Portale von Banken bei­spiels­wei­se brechen die Session bereits nach wenigen Minuten ohne Be­nut­zer­ein­ga­be ab. Andere Websites (wie zum Beispiel viele Social-Media-Portale), die mit weniger sensiblen Daten arbeiten, lassen Sessions al­ler­dings auch über Tage aktiv. Sobald der Nutzer nicht mehr in dem Portal an­ge­mel­det ist, kann eine CSRF-Attacke nicht mehr wirken.