--- id: CP-053 slug: csrf-websiteuebergreifende-anfragefaelschung lang: de title: "CSRF: Aktionen, die ohne Ihr Wissen ausgelöst werden" description: Eine präparierte Website oder Nachricht kann Ihren Browser dazu bringen, in Ihrem Namen auf einem Dienst zu handeln, bei dem Sie angemeldet sind. canonical_url: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ markdown_url: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: "Brain, „CSRF: Aktionen, die ohne Ihr Wissen ausgelöst werden“, Cyberpedia, 2026. https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ (CC BY 4.0)" wing: 1 theme: understand_hacking reflex: cr-018 schema: G3 updated: "2026-11-03" translations: de: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ fr: https://startbrain.io/cyberpedia/fr/articles/csrf-requete-forcee-inter-sites/ en: https://startbrain.io/cyberpedia/en/articles/csrf-cross-site-request-forgery/ es: https://startbrain.io/cyberpedia/es/articles/csrf-falsificacion-peticiones-entre-sitios/ sources: - "n": 1 title: Cross Site Request Forgery (CSRF) | OWASP Foundation publisher: OWASP url: https://community.owasp.org/attacks/csrf accessed: "2026-11-03" - "n": 2 title: Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core publisher: Microsoft url: https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 accessed: "2026-11-03" - "n": 3 title: Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html accessed: "2026-11-03" - "n": 4 title: SameSite | OWASP Foundation publisher: OWASP url: https://community.owasp.org/SameSite accessed: "2026-11-03" - "n": 5 title: "CWE - CWE-352: Cross-Site Request Forgery (5.0)" publisher: MITRE url: https://cwe.mitre.org/data/definitions/352.html accessed: "2026-11-03" --- # CSRF: Aktionen, die ohne Ihr Wissen ausgelöst werden CSRF (Cross-Site Request Forgery) ist ein Angriff, der einen Benutzer dazu zwingt, unbeabsichtigte Aktionen in einer Webanwendung auszuführen, bei der er bereits angemeldet ist [1]. Der Angreifer braucht das Passwort des Opfers nicht: Er lässt dessen Browser handeln. Für Beschäftigte sieht das typische Szenario einfach aus. Ein Postfach oder eine Banking-Seite ist in einem Tab geöffnet. Ein Link aus einer E-Mail oder einer Chatnachricht führt auf eine andere Seite, und diese Seite löst im Hintergrund eine Anfrage an den noch angemeldeten Dienst aus [1]. ## In 30 Sekunden - Wo es vorkommt: bei den meisten Webdiensten ohne CSRF-Schutz, wenn Sie im selben Browser einen präparierten Link oder eine präparierte Seite öffnen [1]. - Was der Angreifer will: eine Aktion auslösen, die etwas verändert, etwa eine Überweisung oder eine Passwortänderung [1]. - Der Reflex: Melden Sie sich von einem Dienst ab, sobald Sie ihn nicht mehr benutzen [2]. - Woher die Schwachstelle kommt: aus der Anwendung, nicht vom Benutzer [2]. ## Direkte Fragen ### Stiehlt CSRF mein Passwort? Nein, nicht als solches. Der Angriff nutzt die Identität und die Rechte des Opfers, um an dessen Stelle eine Aktion auszuführen [1]. Er zielt auf Aktionen, die den Zustand des Dienstes ändern, etwa die E-Mail-Adresse oder das Passwort zu ändern oder etwas zu kaufen. Das Opfer zum Abruf von Daten zu zwingen, nützt dem Angreifer nichts, denn die Antwort erhält das Opfer, nicht er [1]. ### Warum befolgt der Dienst eine Anfrage, die ich nicht gewollt habe? Weil er sie nicht von einer legitimen Anfrage unterscheiden kann. Bei den meisten Websites enthalten die Anfragen des Browsers automatisch die zur Website gehörenden Zugangsdaten, etwa das Sitzungscookie [1]. Ist der Benutzer angemeldet, kann die Website die gefälschte Anfrage also nicht von der echten trennen [1]. Die CWE beschreibt die Schwäche so: Die Anwendung prüft nicht oder kann nicht prüfen, ob eine Anfrage vom absendenden Benutzer absichtlich gestellt wurde [5]. ### Bin ich geschützt, wenn der Dienst HTTPS verwendet? Nein. Laut OWASP schützt HTTPS allein nicht vor CSRF, auch wenn es Voraussetzung dafür bleibt, dass die anderen Maßnahmen zuverlässig sind [1]. ### Liegt das Problem bei mir oder bei der Anwendung? Bei der Anwendung. Microsoft sagt es unmissverständlich: CSRF-Schwachstellen sind grundsätzlich ein Problem der Webanwendung, nicht des Endbenutzers [2]. Das Verhalten der Benutzer begrenzt nur die Gefährdung: sich nach der Nutzung abmelden und die Cookies des Browsers regelmäßig löschen [2]. ## In der Haut des Angreifers Der Angreifer sucht zunächst eine Anfrage, die bei einem Dienst etwas verändert, und baut dann eine Adresse oder ein Skript, das sie mit eigenen Werten nachbildet. OWASP nennt das Beispiel einer fiktiven Bank: Die legitime Anfrage überweist 100 Dollar an einen Begünstigten, und der Angreifer setzt sich selbst als Begünstigten ein und erhöht den Betrag [1]. Nun muss das Opfer diese Anfrage laden, während es angemeldet ist. Genannt werden zwei Wege: eine unerwünschte E-Mail mit HTML-Inhalt oder eine Falle auf Seiten, die das Opfer wahrscheinlich besucht, während es seinen Online-Dienst nutzt [1]. Der Angriff kann auch auf der verwundbaren Website selbst gespeichert werden, zum Beispiel in einem Feld, das HTML akzeptiert. Er wird dadurch wahrscheinlicher: Das Opfer ruft eher eine Seite dieser Website auf als eine beliebige Seite im Internet, und es ist dort zwangsläufig bereits angemeldet [1]. ## Was Sie auf dem Bildschirm sehen Oft nichts. Der präparierte Link kann als gewöhnlicher Link getarnt sein, mit einem Text wie „Meine Fotos ansehen“. Er kann auch die Form eines falschen Bildes mit der Größe null haben: Steht es in einer E-Mail, sieht das Opfer nichts, aber der Browser sendet die Anfrage trotzdem, ohne jedes sichtbare Zeichen, dass der Vorgang stattgefunden hat [1]. ```text Neutralisierte Illustration, keine echte Adresse. Getarnter Link: angezeigter Text „Voir mes photos“, versteckte Adresse hxxp://banque[.]exemple[.]invalid/virement?dest=[Konto des Angreifers]&montant=[hoch] Variante: unsichtbares Bild in einer E-Mail, ohne Klick geladen. ``` Erwartet der Dienst eine POST-Anfrage, kann der Angreifer auf seiner Website ein Formular mit versteckten Feldern bereitstellen. Das Opfer hält es für etwas anderes und klickt, oder ein Skript sendet es beim Laden der Seite automatisch ab [1]. In beiden Fällen ist die angezeigte Seite harmlos, und die Aktion läuft woanders ab. ## Unter der Haube Der Mechanismus beruht auf einem normalen Verhalten der Browser. Sie speichern die Cookies, die eine Anwendung ausstellt, darunter die Sitzungscookies angemeldeter Benutzer, und sie senden bei jeder Anfrage alle Cookies einer Domain mit, gleichgültig, wie diese Anfrage im Browser entstanden ist [2]. Cookies sind nicht der einzige Auslöser: Auch die Authentifizierung per Basic und Digest ist anfällig, weil der Browser die Zugangsdaten bis zum Ende der Sitzung automatisch erneut sendet [2]. Mehrere Verteidigungsideen funktionieren laut OWASP nicht [1]: - ein geheimes Cookie, da bei jeder Anfrage alle Cookies mitgesendet werden; - nur POST-Anfragen zu akzeptieren, da ein verstecktes Formular genügt, um eine zu fälschen; - Transaktionen in mehreren Schritten, solange der Angreifer jeden Schritt vorhersehen kann; - die alleinige Prüfung des Referer-Headers, da er gefälscht werden kann und aus Datenschutzgründen manchmal fehlt. Die empfohlenen Schutzmaßnahmen auf Seiten der Anwendung sind die folgenden. - Zuerst prüfen, ob das Framework bereits einen CSRF-Schutz bietet, und diesen nutzen. Andernfalls allen Anfragen, die den Zustand ändern, Anti-CSRF-Token hinzufügen und sie serverseitig validieren [3]. Ohne Token kann der Angreifer keine gültige Anfrage bauen [3]. - Bei Software ohne Zustand ein Double-Submit-Cookie verwenden, vorzugsweise signiert [3]. - Das Attribut SameSite für Sitzungscookies setzen [3]. Beim Wert strict sendet der Browser das Cookie nicht bei websiteübergreifenden Anfragen, auch nicht, wenn man einem gewöhnlichen Link folgt. Bei lax sendet er es für einen Link, dem man von einer anderen Website aus folgt, hält es aber bei Methoden zurück, die für CSRF anfällig sind, wie POST [4]. Bei none bietet das Attribut keinen Schutz [4]. - Den Ursprung mit Standard-Headern prüfen, insbesondere Sec-Fetch-Site, das seit März 2023 von allen großen Browsern unterstützt wird [3]. - Keine GET-Anfragen für Vorgänge verwenden, die den Zustand ändern [3]. Diese Maßnahmen haben Grenzen. SameSite=Lax lässt GET-Anfragen der Navigation auf oberster Ebene durch: Ein Endpunkt, der den Zustand per GET ändert, bleibt verwundbar [2]. Ältere Browser wenden SameSite möglicherweise nicht an [2]. Und eine XSS-Schwachstelle kann alle Anti-CSRF-Schutzmaßnahmen umgehen; der Samy-Wurm etwa nutzte einen XMLHttpRequest, um das CSRF-Token zu erhalten und Anfragen zu fälschen [1][3]. Das Standardverhalten von SameSite ist uneinheitlich: Im Dezember 2024 war lax der Standardwert in Chrome, Edge und Opera, aber in keiner Version von Firefox oder Safari, weshalb empfohlen wird, den Wert ausdrücklich zu setzen [4]. ## Fallanalysen ### 2008: der uTorrent-Exploit OWASP nennt als reales Beispiel für einen CSRF-Angriff auf eine Anwendung, die über GET-Anfragen arbeitet, einen Exploit gegen uTorrent aus dem Jahr 2008. Er wurde in großem Umfang genutzt, um Schadsoftware herunterzuladen [1]. Mehr sagt die Quelle nicht: weder die Zahl der Opfer noch den Verbreitungsweg. ### In der CWE katalogisierte Schwachstellen (Kennungen von 2004 bis 2009) CWE-352 enthält eine Auswahl beobachteter Beispiele, die nicht vollständig ist [5]. Mehrere beruhen auf einer einfachen URL in einem img-Tag: CVE-2004-1703 und CVE-2004-1995 erlauben das Hinzufügen von Benutzerkonten, CVE-2004-1842 das Erlangen von Administratorrechten [5]. Andere betreffen die Verwaltung selbst: CVE-2009-3520 erlaubt es, das Passwort des Administrators zu ändern, und CVE-2009-3759, über eine Weboberfläche Passwörter zu ändern oder eine virtuelle Maschine herunterzufahren [5]. ## Quellen 1. OWASP, „Cross Site Request Forgery (CSRF) | OWASP Foundation“. https://community.owasp.org/attacks/csrf (abgerufen am 3. November 2026) 2. Microsoft, „Prevent Cross-Site Request Forgery (XSRF/CSRF) attacks in ASP.NET Core“. https://learn.microsoft.com/en-us/aspnet/core/security/anti-request-forgery?view=aspnetcore-10.0 (abgerufen am 3. November 2026) 3. OWASP, „Cross-Site Request Forgery Prevention - OWASP Cheat Sheet Series“. https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html (abgerufen am 3. November 2026) 4. OWASP, „SameSite | OWASP Foundation“. https://community.owasp.org/SameSite (abgerufen am 3. November 2026) 5. MITRE, „CWE - CWE-352: Cross-Site Request Forgery (5.0)“. https://cwe.mitre.org/data/definitions/352.html (abgerufen am 3. November 2026) --- Originalquelle: Cyberpedia, die öffentliche Enzyklopädie zu Cybersicherheit und KI von Brain. Kanonische Version: https://startbrain.io/cyberpedia/de/articles/csrf-websiteuebergreifende-anfragefaelschung/ Sie dürfen diesen Text unter der Lizenz CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) frei weiterverwenden, sofern Sie „Brain, Cyberpedia“ mit einem Link auf die obige Adresse nennen.