CSRF

CSRF (Cross-Site Request Forgery) ist ein Angriff, bei dem eine bösartige Website den Browser eines Opfers dazu bringt, eine authentifizierte Anfrage gegen eine Zielseite abzusetzen, wobei die Cookies genutzt werden, die der Browser automatisch anhängt.

Klassisches Beispiel: Sie sind bei bank.example.com angemeldet. Sie besuchen evil.example, die <img src="https://bank.example.com/transfer?to=attacker&amount=1000" /> enthält. Ihr Browser sendet die Anfrage brav mit Ihren Bank-Sitzungs-Cookies. Die Bank, die die legitime Herkunft nicht unterscheiden kann, führt die Überweisung aus.

Moderne Abwehrmaßnahmen:

• SameSite-Cookie-Attribut (Standard Lax in modernen Browsern) – blockiert Cookies bei seitenübergreifenden POST-Anfragen.
• CSRF-Token – zufällige, vom Server ausgegebene Token, die in Formulare eingebettet und bei der Übermittlung geprüft werden. Seit Jahrzehnten Industriestandard.
• Validierung des Origin-/Referer-Headers – zusätzliche Verteidigungsebene.
• Bearer-Token-Authentifizierung (in Headern, nicht in Cookies) – standardmäßig immun gegen CSRF.

Moderne Frameworks (Django, Rails, Spring) liefern den CSRF-Schutz standardmäßig aktiviert aus. Die Umstellung auf Standard-Lax-Cookies 2020 hat CSRF für die meisten modernen Anwendungen ohne jede Codeänderung praktisch beseitigt.

Durchgerechnetes Beispiel

Eine Schwachstelle aus dem Jahr 2008 in vielen Heimroutern veranschaulicht den klassischen Angriff. Die Admin-Oberfläche des Routers lag unter http://192.168.1.1/, nutzte Basic-Auth-Cookies und stellte ein Formular wie POST /apply.cgi?dns=... zum Ändern des DNS-Servers bereit. Ein Angreifer kontrollierte eine separate Website, die ein unsichtbares, automatisch absendendes Formular enthielt, das auf diese URL zielte. Besuchte ein angemeldeter Nutzer die bösartige Seite, sendete sein Browser das Formular still an seinen Router – mit automatisch angehängten Auth-Cookies –, und der DNS wurde durch den des Angreifers ersetzt. Aus Sicht des Routers sah jede Anfrage legitim aus. Die Lösung, auf die sich die Branche einigte: ein sitzungsspezifischer CSRF-Token im Formular, der bei der Übermittlung validiert wird, sowie das Abweisen von Anfragen, bei denen der Token fehlt oder falsch ist. Eine zweite Lösung kam mit SameSite=Lax-Cookies in Chrome 80 (2020) – der Browser hört auf, Cookies bei seitenübergreifenden POSTs zu senden, und vereitelt den Angriff auf Cookie-Ebene unabhängig von serverseitigen Prüfungen.

Wann und warum es zählt

CSRF ist immer dann relevant, wenn eine Anwendung Nutzer über Cookies authentifiziert, die der Browser automatisch anhängt – was auf die meisten Legacy-Webanwendungen und viele moderne zutrifft. Der Fehler besteht in der Annahme, „wir sind eine API, CSRF betrifft uns nicht“: Wenn die API Sitzungs-Cookies (statt Bearer-Token) verwendet und formularkodierte oder einfache JSON-POSTs ohne Preflight akzeptiert, ist sie verwundbar. Der zweite Fehler ist, sich allein auf den Referer-Header zu verlassen – viele Unternehmens-Proxys und Datenschutz-Tools entfernen ihn und brechen so legitime Nutzer. Das moderne Minimum für eine cookie-basierte Anwendung: SameSite=Lax (oder Strict für sensible Endpunkte) auf allen Auth-Cookies setzen, bei jeder zustandsändernden Anfrage einen CSRF-Token validieren und Anfragen mit nicht übereinstimmenden Origin-Headern an JSON-Endpunkten abweisen. Für neue APIs steigt man vollständig auf Bearer-Token-Authentifizierung über den Authorization-Header um, und die Angriffsfläche verschwindet. Quelle: OWASP — Cross-Site Request Forgery.

Das Double-Submit-Cookie-Muster: Wenn ein Backend keinen sitzungsspezifischen Zustand speichern kann, lässt sich der CSRF-Token per Cookie ausgeben und muss zusätzlich in einem benutzerdefinierten Anfrage-Header erscheinen. Der Browser hängt das Cookie automatisch an jede Anfrage an, doch seitenübergreifende Seiten können seinen Wert nicht lesen, um ihn in den Header zu kopieren – die Same-Origin-Policy blockiert den Lesezugriff. Der Server vergleicht beide und weist Abweichungen ab. Dies ist die Technik, die die meisten modernen Single-Page-App-Frameworks (Angular, die Standardkonfiguration von Axios) zur CSRF-Abwehr bei JSON-APIs verwenden.

Warum CSRF zunehmend irrelevant wird: Die Kombination aus SameSite=Lax-Standards (Chrome 80, 2020), Bearer-Token-Authentifizierung und CORS-Preflight bei nicht-einfachen Anfragen hat die praktische Angriffsfläche auf Legacy-formularkodierte Endpunkte geschrumpft, die weiterhin auf Cookies setzen. Für heute neu gebaute APIs beseitigt der vollständige Verzicht auf Cookies zugunsten von Authorization: Bearer <token>-Headern CSRF ohne Aufwand. Das OWASP-Risikoranking verschob CSRF 2017 aus der Top-10-Liste, weil sich die strukturellen Abwehrmaßnahmen so weit verbreitet hatten. Quelle: OWASP CSRF Prevention Cheat Sheet.