Cross-Site-Request-Forgery (CSRF)

Eine Cross-Site-Request-Forgery (abgekürzt CSRF oder XSRF) beschreibt das Unterschieben eines ungewollten Websiteaufrufs durch einen Angreifer. Dies ist stets dann problematisch, wenn dieser Aufruf eine gewisse Aktion für den Benutzer auslöst, beispielsweise wird durch den untergeschobenen Aufruf ungewollt Artikel gekauft oder das Benutzerkonto gelöscht. Somit kann ein Angreifer eure Benutzer verärgern oder gar großen monetären Schaden anrichten. Deswegen sollte jede Seite und jedes Formular welches Aktionen durchführt (beispielsweise Löschung des Accounts, Logout, Bestellung von Artikel usw.) entsprechend gegen Cross-Site-Request-Forgey geschützt werden.

Beispiele - Manipulierte GET-Abfragen

Angenommen ihr habt eine Benutzercommunity, wie beispielsweise ein Webforum. Die Benutzer sind dort in der Lage Bilder zu verlinken die den anderen Nutzer dargestellt werden. Verlinkt nun der Angreifer im Bild zu der Adresse www.eure-seite.de/logout.php (eine Seite die den Benutzer ausloggt), so wird jeder der die Seite mit dem Bild aufruft direkt ausgeloggt. Der Grund dafür ist, dass der Browser versucht das Bild zu laden und sendet an euren Webserver den Abfrage um die Seite logout.php zu laden. Euer Webserver interpretiert dies, als möchte der User sich ausloggen und loggt diesen konform aus.

Besonders problematisch wird es, wenn man mittels Aufruf das eigene Benutzerkonto löschen kann, z.B. durch den Aufruf www.eure-seite.de/konto_loeschung.php. Dies könnte ein Angreifer wieder in ein untergeschobenes Bild packen und jeder der dieses Aufruft dessen Konto wird gelöscht. Oder alternativ sendet der Angreifer direkt diesen Link an eure Mitglieder und verspricht eine Tolle Prämie für den Klick auf den Link.

Man sollte vermeiden bei GET-Abfragen sensible Aktionen (Logout, Bestellung von Ware, Löschung des Accounts etc.) durchzuführen. Nutzt dazu Formulare die per POST übertragen werden.

Beispiele - Manipulierte POST-Abfragen

Neben GET-Methode existiert auch die POST-Methode für HTTP-Anfragen. Die POST-Methode wird dabei hauptsächlich verwendet, um Formulardaten zu übertragen, beispielsweise zur Bestellung von Artikel oder zum Ändern der eigenen Benutzerdaten. Solch einfachen Formulare bieten aber keinen ausreichenden Schutz gegen Cross-Site-Request-Forgey.

Angenommen ihr habt ein Formular mit der eure Benutzer ihr Passwort ändern kann welches als Zielseite (action-Attribut) eure-seite.de/change_password.php hat. Ein Angreifer erstellt nun eine neue Website und verspricht auf dieser Website beispielsweise ein tolles Gewinnspiel. Um an diesem Gewinnspiel teilnehmen zu können, muss der Benutzer einen Button drücken oder seine E-Mail-Adresse eintragen oder oder oder. Diesen Link verteilt der Angreifer nun gezielt an Benutzer eurer Website, beispielsweise per Facebook oder E-Mail.

Was der Benutzer aber nicht sieht, ist dass das Formular eigentlich euer Formular zum Ändern des Passworts ist. Das neue, vom Angreifer gewählte Passwort wird dabei als verstecktes Eingabefeld  im Formular hinterlegt. Sobald der Besucher bei dem Formular auf absenden drückt, werden die Daten an eure-seite.de/change_password.php übertragen. Euer Script denkt nun (sofern der Benutzer noch bei euch eingeloggt ist), dass dieser das Passwort geändert haben möchte und ändert das Passwort je nach Vorgabe des Angreifers. Der Angreifer kann sich dann später mit dem neuen Passwort einloggen und entsprechenden Schaden anrichten.

Jedes Formular welches Daten in eurer Datenbank verändert oder andere kritische Operationen ausführt sollte speziell gegen Cross-Site-Request-Forgery geschützt werden.

Schutz vor CSRF

Der Schutz gegen CSRF ist zum Glück relativ einfach. In eure Formulare und in eure Links die gewisse Aktionen auslösen (z.B. Logout-Link) müsst ihr eine geheime Information einbetten, die nur euer Server und der Browser des Benutzers kennt.

Beispielsweise generiert ihr nach dem Login einen zufälligen Wert und speichert diesen in einer Session ab:

Jedes zu schützende Formular sowie jeder zu schützende Link wird nun dieser CSRF-Token übergeben. Aus dem Logout-Link wird entsprechend logout.php?csrf=$_SESSION['csrf_token'].

Ein zu schützendes Formular wird um ein hidden-Field erweitert, indem der Wert hinterlegt ist:

Auf der Empfängerseite, also in eurem Logout-Script, in den Code-Stellen die eure Formulare etc. verarbeiten, könnt ihr überprüfen ob der übermittelte Wert dem abgespeicherten Wert in der Session entspricht:

Das Unterschieben von Links oder Formularen wird dadurch verhindert. Sofern ihr diesen Schutz also überall konsequent implementiert habt, ist eure Webanwendung recht sicher gegen Cross-Site-Request-Forgery.