Cross-Site-Request-Forgery

Eine Cross-Site-Request-Forgery (meist CSRF oder XSRF abgekürzt, deutsch etwa „Webseitenübergreifende Anfragenfälschung“, auch Session-Riding genannt) 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 eine HTTP-Anfrage untergeschoben. Der Angreifer wählt die Anfrage so, dass bei deren Aufruf die Webanwendung die vom Angreifer gewünschte Aktion ausführt.

Das Sicherheitsproblem ist auf die Zustandslosigkeit von HTTP zurückzuführen, da nach einmaliger Authentifizierung der Browser implizit jedes Mal seine Sitzungsdaten an den Server sendet.

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

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^[1] 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.

Ein recht harmloses Beispiel einer CSRF wäre ein Link auf der Webseite des Angreifers zu der Abmelden-Funktion auf der Wikipedia:

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

Wird einem in der Wikipedia angemeldeten Benutzer dieser Link untergeschoben, sodass sein Browser diese Anfrage absetzt, wird er ohne eigenes Zutun von der Wikipedia abgemeldet, vorausgesetzt die Webanwendung auf Wikipedia hat keinen Schutz gegen CSRF-Angriffe. In der Realität muss die Abmeldung bei der Wikipedia hier allerdings noch einmal bestätigt werden und der eigentliche Logout-Vorgang funktioniert über eine POST-Anfrage.

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

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

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

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-Anfragen auszuführen. Hierzu gibt es mehrere Angriffsvektoren:

Mittels Cross-Site-Scripting (XSS) kann ein Angreifer z. B. einen img- oder script-Tag in die Webanwendung einbauen, der einen Http-Request verursacht. Vor dieser Methode kann sowohl die Same-Origin-Policy als auch das SameSite-Attribut nicht schützen, da die Anfragen von innerhalb der Webanwendung ausgehen. Die Methode mit einem script-Tag erlaubt es dem Angreifer sogar auch POST-Requests zu senden. Vor dieser Bedrohung schützen die unten stehenden Abwehrmaßnahmen allerdings nicht, denn das eigentliche Problem liegt hier in der XSS-Lücke.

Existieren in einer Webanwendung GET-Schnittstellen, die Daten am Server verändern, ist es möglich ein eingeloggtes Opfer mittels Social Engineering dazu zu bringen auf einen Link zu klicken, durch den das Opfer unwissentlich dann eine vom Angreifer gewünschte Aktion auf der Webseite ausführt.

Alternativ könnte der Angreifer solch eine URL z. B. in einem img-Tag auf einer eigenen Webseite verstecken und das Opfer dann auf diese Seite locken, wodurch die GET-Anfrage ausgeführt würde.

Lockt ein Angreifer ein Opfer auf die eigene Webseite, kann er ein verstecktes Formular in die Webseite einbauen, das einen POST-Endpunkt einer anderen Webseite, auf der das Opfer eingeloggt ist, als Ziel hat. Die Same-Origin-Policy verhindert zwar lesenden Zugriff auf andere Webseiten, aber die Anfrage wird trotzdem zuerst abgeschickt, um auf CORS-Header zu prüfen und dann wird die Antwort erst gegebenenfalls verworfen. Der Server hat diese dann bereits empfangen und damit die vom Angreifer gewünschte Aktion ausgeführt.

Bei vielen Arten von durch JavaScript veranlassten POST-Anfragen wird vorher eine Preflight-Check-Anfrage gesendet, die die Kontrolle der CORS-Header ermöglicht, ohne die eigentliche Post-Request zu senden. Bei Formularen ist dies allerdings aus Gründen der Rückwärtskompatibilität nicht der Fall, weswegen dieser Angriff auch in modernen Browsern möglich ist, indem man mittels JavaScript ein verstecktes Formular erstellt und absendet.

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.

Die Sicherheitskonzepte der Browser basieren darauf, dass GET-Anfragen zu keiner Veränderung von Daten auf dem Server führen. Sollen Daten verändert werden, sollte dafür über POST-, PUT-, PATCH- oder DELETE-Schnittstellen verwendet werden.

Dies verhindert einfache Angriffe wie ein Unterschieben der URL, da das Anklicken eines Links erstmal nur eine GET-Anfrage auslöst, schützt aber nicht vor raffinierteren Angriffen wie z. B. durch Schädliche Formulare.

Das SameSite-Attribut spezifiziert, wie ein Cookie beim Aufruf der Seite aus dem Zugriffskontext anderer Seiten verwendet werden darf. In heutigen Browsern stellt SameSite=Strict einen wirksamen Schutz gegen CSRF dar. Falls auf der Seite keine sensitiven Aktionen durch GET-Requests ausgeführt werden können, reicht auch SameSite=Lax aus.

SameSite=Lax ist in modernen Browsern bereits die Standardeinstellung für Cookies. Daher reicht es eigentlich aus, dass die HTTP-Methoden korrekt genutzt werden (siehe oben). Da dieser Standardwert sich aber erst in den letzten Jahren durchgesetzt hat, ist das explizite Setzen des Attributs noch notwendig.

Falls explizit stark veraltete (unsichere) Browser verwendet werden, müssen jedoch zusätzlich weitere Sicherheitsvorkehrungen (wie CSRF-Tokens) getroffen werden.

Außerdem bietet SameSite nur Schutz, wenn es für einen Angreifer nicht möglich ist, diesen unter derselben eTLD+1 (also dem Domainteil bis ein Level vor einer in der Public Suffix List festgelegten Endung z. B. „example.org“ bei „test.example.org“) zu hosten. Wären beispielsweise GitHub Pages nicht auf „github.io“, sondern auf „github.com“ gehostet, würde das SameSite-Attribut als Schutz für GitHub nicht ausreichen.

Bei STP wird ein sogenanntes Page-Token, meistens eine Zahl oder eine Zeichenkette, in einem Hidden-Field auf der Seite eingebunden.

<input type="hidden" name="csrftoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />

Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field für den Angreifer nicht auslesbar. Insbesondere eine XSS-Schwachstelle kann jedoch den CSRF-Schutz aushebeln. Letzteres gilt selbst dann, wenn die XSS-Schwachstelle bloß in einer anderen Anwendung auf derselben Domain existiert.^[2]

Wie das Feld gesetzt wird, ist abhängig vom verwendeten Framework.

Beispiel in ASP.NET MVC

In ASP.NET MVC werden alle Forms automatisch mit einem Hidden-Field mit dem Anti-CSRF-Token versehen:

@using (Html.BeginForm("ChangePassword", "Manage"))
{
    // ...
}

Alternativ lässt sich dieses auch manuell setzen:

<form action="/" method="post">
    @Html.AntiForgeryToken()
</form>

Zudem gibt es in ASP.NET Core mit Microsoft.AspNetCore.Antiforgery die Möglichkeit das Token auch global zu konfigurieren:

services.AddAntiforgery(options => {
    options.FormFieldName = "csrftoken";
    options.RequireSsl = true;
});

Die Validierung des Tokens muss auf allen MVC-Controllern bzw. Methoden erfolgen, welche eine Nebenwirkung besitzen. Hierzu dienen drei Filter, welche als Attribute auf den entsprechenden Controllern bzw. Methoden gesetzt werden können:

Filter auf den Methoden überschreiben hierbei die Filter auf den Controllern.

Das CSRF-Token kann auch in einem Cookie gespeichert werden. Dieses wird im HTTP-Header deklariert:

Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2017 10:25:33 GMT; Max-Age=31449600; Path=/

Das Flag httpOnly ist hierbei nicht zulässig, da das Token im Browser durch ein JavaScript-Skript verarbeitet werden muss.

Bestimmte Frameworks erzwingen eine bestimmte Benennung für das CSRF-Cookie. Beispielsweise muss das Token für das $http-Service in Angular mit XSRF-TOKEN benannt werden. Anschließend wird das Token im X-XSRF-TOKEN-HTTP-Header übermittelt.^[3]

Beispiel in ASP.NET MVC

Mit Microsoft.AspNetCore.Antiforgery lässt sich das Cookie wie folgt setzen:

services.AddAntiforgery(options => {
    options.CookieName = "Csrf-Token";
    options.CookiePath = "/";
    options.CookieDomain = "example.com";
    options.RequireSsl = true;
});

Eine weitere Methode, das Token zu übermitteln, ist der HTTP-Header. Hierzu wird der Header X-Csrf-Token verwendet. Allerdings verwenden einige Frameworks auch vom Standard abweichende Header.

Beispiel in ASP.NET MVC

Mit Microsoft.AspNetCore.Antiforgery lässt sich das Token im HTTP-Header wie folgt setzen:

services.AddAntiforgery(options => {
    options.HeaderName = "X-Csrf-Token";
    options.RequireSsl = true;
});

Bei alten Browsern, die XMLHttpRequests von verschiedenen Origin-Domänen zulassen, müssen XMLHttpRequests abgelehnt werden, wenn die im Origin-HTTP-Header eingetragene Domäne nicht Teil der zulässigen CORS-Domänen ist.

Viele Webanwendungen, wie zum Beispiel auch die Wikipedia, bieten ihren Nutzern die Möglichkeit, dauerhaft angemeldet zu sein. Technisch wird hierbei in der Regel der in einem Cookie gespeicherte Sitzungsbezeichner am Ende einer Sitzung nicht gelöscht. Diese Komfortfunktion vergrößert aber auch die Angriffsfläche, da der Angreifer nicht mehr einen Zeitpunkt abzupassen braucht, 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.

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.

Die Prüfung des HTTP-Referrer-Headers bietet zwar einen gewissen Schutz vor reinen CSRF-Angriffen, da gefälschte Anfragen, die von einem Angreifer mittels Täuschung des Opfers auf einer externen Webseite ausgelöst wurden, zum Teil blockiert werden können. Die Webanwendung ist jedoch gut beraten, sich nicht auf den Schutz des Referrers zu verlassen: Viele Browser-Plugins erlauben es nämlich, Anfragen mit beliebigem Referrer abzusetzen, z. B. das früher weit verbreitete Adobe Flash^[4]. 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 eine HTTP-Anfrage verwenden.

• Norman Hardy: The Confused Deputy: (or why capabilities might have been invented). In: ACM SIGOPS Operating Systems Review, Oktober 1988, Volume 22, Issue 4.

• CSRF Angriffe (Teil 2): Schwache Gegenmaßnahmen. cubespotter.de, Juni 2017.
• Querschau der Risiken. Heise, 2010.
• OWASP Top 10-2017. (PDF) Open Web Application Security Project.
• Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. OWASP.
• National Vulnerability Database web site. nist.gov
• Security tips for Web developers. squarefree.com (englisch).
• Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen. (PDF; 922 kB) Bundesamt für Sicherheit in der Informationstechnik (BSI).
• Session-Angriffe – eine Analyse. erich-kachel.de
• CSRF-Angriffe auf Router und Webanwendungen. TecChannel, 2009.
• RFC2616 – Hypertext Transfer Protocol – HTTP/1.1. Juni 1999, Abschnitt 9.1.1: Safe Methods. (englisch).
• The Cross-site Request Forgery FAQ. cgisecurity.com
• Sverre Huseby: Client Side Trojans. shh.thathost.com
• Foiling Cross-Site Attacks. shiflett.org, 2003.
• Concerns over the name “Session Riding”. shiflett.org/blog, 2005
• Do I still need CSRF protection when SameSite is set to Lax? security.stackexchange.com, 2021.
• Using HTTP cookies developer.mozilla.org/en-US/docs/, 2024.
• SameSite-Attribut: Google Chrome drängt auf sichere Cookies www.heise.de/news, 2020.

1. ↑ Peter Watkins: Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images). Bugtraq, 13. Juni 2001, archiviert vom Original (nicht mehr online verfügbar) am 9. Juli 2012; abgerufen am 26. Juli 2012 (englisch). 
2. ↑ Christian Schneider: CSRF and Same-Origin XSS. 25. Februar 2012; abgerufen am 13. Dezember 2014.
3. ↑ Guarding against Cross-Site Request Forgery. In: Angular.io. Google, abgerufen am 15. Mai 2017 (englisch). 
4. ↑ Forging HTTP Request Headers with Flash ActionScript. In: securiteam.com. 4. Januar 2013, archiviert vom Original (nicht mehr online verfügbar) am 4. Januar 2013; abgerufen am 24. Januar 2022.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.securiteam.com