imported>Siegbert v2: /* Weblinks */ Archivversion für tote oder inzwischen nicht mehr öffentlich zugängliche Links

2026-03-07T08:44:29Z

Weblinks: Archivversion für tote oder inzwischen nicht mehr öffentlich zugängliche Links

Neue Seite

Eine '''Cross-Site-Request-Forgery''' (meist '''CSRF''' oder '''XSRF''' abgekürzt, deutsch etwa „[[Website]]<nowiki/>übergreifende Anfragenfälschung“, auch '''Session-Riding''' genannt) ist ein Angriff auf ein [[Computer]]system, 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 [[Hypertext Transfer Protocol#HTTP-Anfragemethoden|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 [[HTTP-Authentifizierung#Basic Authentication|Basic]]- bzw. [[HTTP-Authentifizierung#Digest Access Authentication|Digest]]-Authentifizierung auf.

== Geschichte ==
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 (Webanwendungsserver)|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<ref>{{Internetquelle |autor=Peter Watkins |url=http://www.tux.org/~peterw/csrf.txt |titel=Cross-Site Request Forgeries (Re: The Dangers of Allowing Users to Post Images) |hrsg=Bugtraq |datum=2001-06-13 |sprache=en |offline=1 |archiv-url=https://web.archive.org/web/20120709094554/http://www.tux.org/~peterw/csrf.txt |archiv-datum=2012-07-09 |abruf=2012-07-26}}</ref> 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.

== Beispiele ==
Ein recht harmloses Beispiel einer CSRF wäre ein Link auf der Webseite des Angreifers zu der Abmelden-Funktion auf der Wikipedia:
<nowiki>https://</nowiki>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 [[Hypertext Transfer Protocol#HTTP POST|POST]]-Anfrage.

Schwerwiegender wäre eine solche URL bei der Benutzerverwaltung einer nicht öffentlichen Seite. Zum Beispiel könnte der Angreifer mit
<nowiki>https://</nowiki>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.

== 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-Anfragen auszuführen. Hierzu gibt es mehrere [[Angriffsvektor]]en:

=== Cross-Site-Scripting ===
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 [[Cross-Site-Request-Forgery#SameSite-Attribut|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 [[Hypertext Transfer Protocol#HTTP POST|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.

=== Unterschieben der URL ===
Existieren in einer Webanwendung GET-Schnittstellen, die Daten am Server verändern, ist es möglich, ein eingeloggtes Opfer mittels [[Social Engineering (Sicherheit)|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.

=== Schädliche Formulare ===
Lockt ein Angreifer ein Opfer auf die eigene Webseite, kann er ein verstecktes [[Webformular|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 [[Cross-Origin Resource Sharing|CORS]]-Header zu prüfen, und erst dann wird die Antwort 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.

== 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 ===

==== Nutzung korrekter HTTP-Methoden ====
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, so sollten dafür '''POST'''-, '''PUT'''-, '''PATCH'''- oder '''DELETE'''-Schnittstellen verwendet werden.

Dies verhindert einfache Angriffe wie ein [[Cross-Site-Request-Forgery#Unterschieben der URL|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 [[Cross-Site-Request-Forgery#Schädliche Formulare|Schädliche Formulare]].

{{Siehe auch|Hypertext Transfer Protocol#HTTP-Anfragemethoden}}

==== SameSite-Attribut ====
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#GitHub Pages|GitHub Pages]] nicht auf „github.io“, sondern auf „github.com“ gehostet, würde das SameSite-Attribut als Schutz für [[GitHub]] nicht ausreichen.

==== Synchronizer Token Pattern (STP) ====
Bei STP wird ein sogenanntes Page-Token, meistens eine Zahl oder eine Zeichenkette, in einem [[Hidden-Field]] auf der Seite eingebunden.
<syntaxhighlight lang="html">
<input type="hidden" name="csrftoken" value="KbyUmhTLMpYj7CD2di7JKP1P3qmLlkPt" />
</syntaxhighlight>

Ohne weitere Lücken in der Webanwendung ist dieses Hidden-Field für den Angreifer nicht auslesbar. Insbesondere eine [[Cross-Site-Scripting|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.<ref>Christian Schneider: [http://www.christian-schneider.net/CsrfAndSameOriginXss.html ''CSRF and Same-Origin XSS.''] 25. Februar 2012; abgerufen am 13. Dezember 2014.</ref>

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:
<syntaxhighlight lang="csharp">
@using (Html.BeginForm("ChangePassword", "Manage"))
{
// ...
}
</syntaxhighlight>
Alternativ lässt sich dieses auch manuell setzen:
<syntaxhighlight lang="csharp">
<form action="/" method="post">
@Html.AntiForgeryToken()
</form>
</syntaxhighlight>

Zudem gibt es in ASP.NET Core mit <code>Microsoft.AspNetCore.Antiforgery</code> die Möglichkeit das Token auch global zu konfigurieren:
<syntaxhighlight lang="csharp">
services.AddAntiforgery(options => {
options.FormFieldName = "csrftoken";
options.RequireSsl = true;
});
</syntaxhighlight>

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:

{| class="wikitable"
! Attribut !! Funktion
|-
| <syntaxhighlight lang="csharp" inline>[ValidateAntiForgeryToken]</syntaxhighlight>
| Validiert das CSRF-Token
|-
| <syntaxhighlight lang="csharp" inline>[AutoValidateAntiforgeryToken]</syntaxhighlight>
| Validiert das CSRF-Token für alle HTTP-Methoden ausgenommen <code>GET</code>, <code>HEAD</code>, <code>OPTIONS</code>, <code>TRACE</code>. Hierbei müssen die entsprechenden Methoden standardkonform implementiert werden.
|-
| <syntaxhighlight lang="csharp" inline>[IgnoreAntiforgeryToken]</syntaxhighlight>
| Keine Validierung
|}
Filter auf den Methoden überschreiben hierbei die Filter auf den Controllern.

==== Cookie ====
Das CSRF-Token kann auch in einem [[HTTP-Cookie|Cookie]] gespeichert werden. Dieses wird im HTTP-Header deklariert:
<syntaxhighlight lang="http">
Set-Cookie: Csrf-token=i8XNjC4b8KVok4uw5RftR38Wgp2BFwql; expires=Thu, 23-Jul-2017 10:25:33 GMT; Max-Age=31449600; Path=/
</syntaxhighlight>
Das Flag <code>httpOnly</code> 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 <code>$http</code>-Service in [[Angular]] mit <code>XSRF-TOKEN</code> benannt werden. Anschließend wird das Token im <code>X-XSRF-TOKEN</code>-HTTP-Header übermittelt.<ref>{{Internetquelle |url=https://angular.io/docs/ts/latest/guide/server-communication.html#!#xsrf |titel=Guarding against Cross-Site Request Forgery |werk=Angular.io |hrsg=Google |sprache=en |abruf=2017-05-15}}</ref>

'''Beispiel in ASP.NET MVC'''

Mit <code>Microsoft.AspNetCore.Antiforgery</code> lässt sich das Cookie wie folgt setzen:
<syntaxhighlight lang="csharp">
services.AddAntiforgery(options => {
options.CookieName = "Csrf-Token";
options.CookiePath = "/";
options.CookieDomain = "example.com";
options.RequireSsl = true;
});
</syntaxhighlight>

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

{| class="wikitable"
|+ Beispiele für Frameworks mit nicht-standardisierten CSRF-Header
! Header !! Framework
|-
| <code>X-XSRF-TOKEN</code> || [[Angular]]
|-
| <code>X-Requested-With</code> || [[jQuery]]
|-
| <code>X-Requested-By</code> || [https://jersey.github.io/ Jersey]
|}

'''Beispiel in ASP.NET MVC'''

Mit <code>Microsoft.AspNetCore.Antiforgery</code> lässt sich das Token im HTTP-Header wie folgt setzen:
<syntaxhighlight lang="csharp">
services.AddAntiforgery(options => {
options.HeaderName = "X-Csrf-Token";
options.RequireSsl = true;
});
</syntaxhighlight>

==== Behandlung von XMLHttpRequests ====
Bei alten Browsern, die <code>XMLHttpRequest</code>s von verschiedenen Origin-Domänen zulassen, müssen <code>XMLHttpRequest</code>s abgelehnt werden, wenn die im Origin-HTTP-Header eingetragene Domäne nicht Teil der zulässigen [[Cross-Origin Resource Sharing|CORS]]-Domänen ist.

=== Clientseitig ===
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.

== 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.

=== HTTP-Referrer-Prüfung ===
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]]<ref>{{Internetquelle |url=http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html |titel=Forging HTTP Request Headers with Flash ActionScript |werk=securiteam.com |datum=2013-01-04 |offline=1 |archiv-url=https://web.archive.org/web/20130104232934/http://www.securiteam.com/securityreviews/5KP0M1FJ5E.html |archiv-datum=2013-01-04 |abruf=2022-01-24}}</ref>. 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 positive]]s). Aus Gründen der Benutzbarkeit einer Webanwendung sollte man den Referrer-Header grundsätzlich nicht für eine HTTP-Anfrage verwenden.

== Literatur ==
* Norman Hardy: [https://portal.acm.org/citation.cfm?id=871709 The Confused Deputy: (or why capabilities might have been invented).] In: ''ACM SIGOPS Operating Systems Review'', Oktober 1988, Volume 22, Issue 4.

== Weblinks ==
* {{Webarchiv |url=https://www.cubespotter.de/cubespotter/csrf-attacks-teil2-schwache-gegenmassnahmen/ |wayback=20190716105530 |text=CSRF Angriffe (Teil 2): ''Schwache Gegenmaßnahmen''.}} cubespotter.de, Juni 2017.
* [https://www.heise.de/developer/artikel/Querschau-der-Risiken-1028917.html ''Querschau der Risiken''.] Heise, 2010.
* {{Webarchiv |url=https://www.owasp.org/images/9/90/OWASP_Top_10-2017_de_V1.0.pdf |wayback=20190216182339 |text=OWASP Top 10-2017. |format=PDF}} Open Web Application Security Project.
* [https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet.] OWASP.
* [http://nvd.nist.gov/ National Vulnerability Database web site.] nist.gov
* [http://www.squarefree.com/securitytips/web-developers.html Security tips for Web developers.] squarefree.com (englisch).
* {{Webarchiv |url=https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Studien/WebSec/WebSec.pdf?__blob=publicationFile&v=1 |wayback=20170315004535 |text=Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen. |format=PDF; 922 kB}} Bundesamt für Sicherheit in der Informationstechnik (BSI).
* [https://www.erich-kachel.de/?p=368 Session-Angriffe – eine Analyse.] erich-kachel.de
* {{Webarchiv |url=http://www.tecchannel.de/webtechnik/webserver/1993878/csrf_attacke_auf_dsl_router_und_web_anwendungen/index.html |wayback=20140711152711 |text=CSRF-Angriffe auf Router und Webanwendungen.}} TecChannel, 2009.
* {{RFC-Internet |RFC=2616 |Titel=Hypertext Transfer Protocol – HTTP/1.1 |Datum=1999-06 |Abschnitt=9.1.1 |Abschnittstitel=Safe Methods}}
* [http://www.cgisecurity.com/csrf-faq.html The Cross-site Request Forgery FAQ.] cgisecurity.com
* Sverre Huseby: [http://shh.thathost.com/text/client-side-trojans.txt Client Side Trojans.] shh.thathost.com
* [http://shiflett.org/articles/foiling-cross-site-attacks Foiling Cross-Site Attacks.] shiflett.org, 2003.
* [http://shiflett.org/blog/2005/session-riding Concerns over the name “Session Riding”.] shiflett.org/blog, 2005 
* [https://security.stackexchange.com/questions/234386/do-i-still-need-csrf-protection-when-samesite-is-set-to-lax Do I still need CSRF protection when SameSite is set to Lax?] security.stackexchange.com, 2021.
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies Using HTTP cookies] developer.mozilla.org/en-US/docs/, 2024.
* [https://www.heise.de/news/SameSite-Attribut-Google-Chrome-draengt-auf-sichere-Cookies-4768780.html SameSite-Attribut: Google Chrome drängt auf sichere Cookies] www.heise.de/news, 2020.

== Einzelnachweise ==
<references />

[[Kategorie:Sicherheitslücke]]
[[Kategorie:Web-Entwicklung]]

Cross-Site-Request-Forgery - Versionsgeschichte

imported>Siegbert v2: /* Weblinks */ Archivversion für tote oder inzwischen nicht mehr öffentlich zugängliche Links