CSRF-Grundlagen

Was CSRF ist

CSRF nutzt eine spezifische Browser-Eigenschaft aus: Cookies werden automatisch mit Cross-Site-Requests mitgesendet (oder wurden es zumindest historisch).

Stell dir vor, du bist bei deiner Bank bank.example eingeloggt. Dein Browser hat ein Session-Cookie. Du öffnest in einem anderen Tab eine Angreifer-Seite evil.example. Diese Seite enthält versteckt:

<!-- Auf evil.example -->
<form action="https://bank.example/transfer" method="POST" id="csrf">
  <input name="to" value="attacker-account">
  <input name="amount" value="10000">
</form>
<script>document.getElementById('csrf').submit();</script>

Wenn du evil.example aufrufst, submittet das Formular automatisch eine POST-Anfrage an die Bank. Dein Browser sendet dabei dein Bank-Session-Cookie mit — die Bank sieht eine authentifizierte Anfrage und führt die Überweisung aus. Ohne dein Wissen, ohne dein aktives Zutun.

Das ist CSRF: der Angreifer nutzt deine Authentifizierung aus, ohne sie zu kennen.

Wichtige Unterschiede zu XSS:

• CSRF läuft auf einer fremden Origin (evil.example) und schickt eine Anfrage an die Ziel-Origin (bank.example).
• XSS läuft innerhalb der Ziel-Origin — der schadhafter Code wird auf bank.example selbst ausgeführt.

CSRF ist „ich kenne dein Passwort nicht, aber ich nutze deinen Browser". XSS ist „ich bin in deiner Origin und sehe alles".

Voraussetzungen für CSRF

CSRF funktioniert nur unter bestimmten Bedingungen:

• Opfer ist eingeloggt in der Ziel-Anwendung — sonst gibt es kein Session-Cookie, das missbraucht werden kann.
• Authentifizierung läuft über Cookies (oder ähnliche Browser-State-Mechanik) — Bearer-Token-Header werden nicht automatisch mitgesendet.
• Aktion ist über eine simple HTTP-Anfrage auslösbar — typisch POST mit Form-Daten oder GET mit Side-Effects.
• Anwendung prüft nicht, ob die Anfrage von der eigenen Origin kommt.

Wenn auch nur eine dieser Bedingungen nicht erfüllt ist, ist CSRF strukturell schwer:

• Nicht eingeloggt → kein State zu missbrauchen.
• Bearer-Token (JWT in Header) → kein automatisches Mitsenden.
• Action verlangt JavaScript-State (Custom-Header, Cookies-from-Different-Domain) → automatisches Mitsenden klappt nicht.
• Origin-Check oder CSRF-Token → Angreifer-Anfrage scheitert.

Genau diese Bedingungen sind in den letzten Jahren durch SameSite-Cookies und durch den Trend zu Bearer-Token-Auth in SPAs deutlich gebrochen worden.

Klassische CSRF-Vektoren

Historisch funktionierten viele unterschiedliche Wege, eine fremde Anfrage auszulösen:

Auto-Submitting Form — wie oben gezeigt; HTML-Formular per JavaScript abgeschickt.

Bild-Tag mit GET-Action:

<!-- GET-Endpoint mit Side-Effect — schlechtes Design -->
<img src="https://bank.example/transfer?to=attacker&amount=10000">

Browser lädt das „Bild" — schickt dabei den Request mit Cookies. Wenn der Bank-Endpunkt eine GET-Aktion mit Wirkung hat, klappt CSRF ohne Form.

iframe mit Form-Submit — versteckt im DOM, ohne Sicht:

<iframe style="display:none" name="hidden"></iframe>
<form action="https://bank.example/transfer" method="POST" target="hidden">
  <input name="to" value="attacker">
</form>
<script>document.forms[0].submit();</script>

JSON-Request via XMLHttpRequest — funktioniert nur, wenn CORS es erlaubt; klassisch durch SOP blockiert.

WebSocket-Connection — selten als CSRF-Vektor genutzt, aber Cookies werden mitgesendet.

Die meisten Vektoren haben gemeinsam: kein User-Aktiv-Klick auf der Ziel-Site, aber automatisch mitgesendete Cookies.

Was sich seit 2020 geändert hat

Die wichtigste strukturelle Änderung: SameSite-Cookies als Browser-Default.

Seit Chrome 80 (2020), Firefox 96 (2022), Edge 80 (2020), Safari 13 (2019, mit Eigenheiten): Cookies ohne explizites SameSite-Attribut werden als SameSite=Lax behandelt.

Was das bedeutet:

• SameSite=Lax — Cookie wird bei Cross-Site-Anfragen nicht mitgesendet, außer bei Top-Level-Navigation per GET (z. B. Link-Klick).
• SameSite=Strict — Cookie wird bei gar keinem Cross-Site-Request mitgesendet.
• SameSite=None; Secure — Cookie wird mitgesendet (alte Behavior); muss explizit gesetzt werden.

Konsequenz für klassisches CSRF: Der Auto-Submitting-Form-Angriff oben funktioniert seit 2020 bei den meisten Sites nicht mehr, weil das Bank-Session-Cookie standardmäßig Lax ist und bei einer Cross-Site-POST-Anfrage nicht mitgesendet wird.

Das ist eine massive Reduktion der CSRF-Angriffsfläche ohne Code-Änderung in den Anwendungen.

Vertieft in samesite-cookies.

Wo CSRF heute noch wichtig ist

Trotz SameSite-Defaults bleibt CSRF relevant in mehreren Konstellationen:

1. Bei expliziter SameSite=None-Konfiguration.

Wenn deine Anwendung bewusst Cookies cross-site funktionsfähig macht (z. B. für Cross-Domain-Auth, Embed-Workflows, OAuth-Flows), ist SameSite=None nötig — und die klassische CSRF-Angriffsfläche kommt zurück. CSRF-Tokens werden dann Pflicht.

2. „Lax + GET-Endpoints" als bekannter Bypass.

SameSite=Lax sendet Cookies bei Top-Level-GET-Navigation mit. Wenn deine Anwendung GET-Endpoints mit Seiteneffekten hat (z. B. GET /logout?user=42), bleibt CSRF möglich. Klassischer Anti-Pattern, der weiter existiert.

3. Bei Pre-2020-Browser-Nutzern.

In manchen Umgebungen (alte Embedded-Geräte, Enterprise-Setups mit eingefrorenen Browser-Versionen) sind SameSite-Defaults nicht aktiv. Wer solche Nutzer:innen erreicht, hat klassisches CSRF-Risiko.

4. In OAuth-Flows.

CSRF in OAuth-Authorization-Code-Flow ist ein eigenständiges Problem — der state-Parameter ist die Antwort. Vertieft in csrf-in-oauth-und-saml.

5. Innerhalb derselben Site.

Subdomains gelten in SameSite-Logik als „Same-Site" (bank.example und api.bank.example teilen sich Cookies). Wenn eine Subdomain XSS hat, kann sie CSRF gegen andere Subdomains ausführen. Subdomain-Hygiene wird damit zur Sicherheits-Frage.

6. Bei nicht-Cookie-Auth, die trotzdem implizit ist.

HTTP-Basic-Auth, NTLM, Kerberos-SPNEGO senden Credentials automatisch mit. SameSite gilt nur für Cookies, nicht für diese Mechanismen. Für interne Apps mit Windows-Auth bleibt CSRF-Risiko.

Diese Konstellationen sind in der Mehrheit aller Web-Apps selten — aber wer eine baut, muss CSRF-Schutz trotzdem implementieren. Defense-in-Depth heißt: nicht auf Browser-Default verlassen, sondern aktive Schutz-Schichten.

Verteidigungs-Schichten

Die Karte für die folgenden Artikel:

In modernen Apps wirken meist mehrere Schichten zusammen — z. B. SameSite=Lax + CSRF-Token + Origin-Check. Eine einzelne Schicht reicht in Edge-Cases nicht.

CSRF in der OWASP Top 10

CSRF hatte in der OWASP Top 10 einen eigenen Platz von 2007 bis 2013 (jeweils unter den ersten 5). Seit OWASP Top 10 2017 ist CSRF nicht mehr in der Liste — die Begründung: moderne Framework-Defaults (CSRF-Token in Django, Rails, Spring, ASP.NET, Laravel, Express CSRF-Middleware) plus SameSite-Cookies haben die Klasse weitgehend gelöst.

Das heißt aber nicht, dass CSRF irrelevant ist — es heißt, dass es in den meisten modernen Apps strukturell schon mitgedacht ist. Pentest-Findings sind seltener, aber in Custom-Auth-Apps, in legacy-Microservices und in OAuth-Integrationen weiterhin regelmäßig zu finden.

Verwandt: Clickjacking (UI-Redress) wird oft mit CSRF verwechselt — beides nutzt Cross-Site-Mechanismen, aber Clickjacking braucht einen Klick der Nutzer:in auf einem überlagerten iframe. Detail in clickjacking-und-ui-redress (Kap 10).

Was du daraus mitnimmst

Praktische Konsequenzen für moderne Web-Apps:

• SameSite=Lax als Default — moderne Browser machen es eh.
• CSRF-Token für klassische Form-basierte Apps — Framework-Default in Django/Rails/Spring/Laravel.
• Origin-Header-Check als zusätzliche Schicht — billig und wirksam.
• Custom-Header-Anforderung für JSON-APIs — strukturell anti-CSRF.
• GET-Endpoints ohne Side-Effects — RESTful-Disziplin schützt indirekt.
• OAuth state-Parameter — Pflicht in jedem OAuth-Flow.
• Re-Auth bei sensitiven Aktionen (Passwort-Wechsel, Auszahlung, OAuth-Verbindung) — fängt selbst CSRF auf legitimer Cookie-Auth ab.

Wenn alle Schichten aktiv sind, ist CSRF praktisch geschlossen. Aber: jede Schicht hat eigene Stolpersteine — und die folgenden Artikel zeigen sie konkret.

Weiterführende Ressourcen

Externe Quellen

• OWASP — Cross-Site Request Forgery (CSRF)
• OWASP CSRF Prevention Cheat Sheet
• PortSwigger Web Security Academy — CSRF
• MDN — Same-Origin Policy
• web.dev — SameSite Cookies Explained
• Wikipedia — CSRF (Historie)

Verwandte Artikel

• SameSite-Cookies
• CSRF-Tokens und Double-Submit
• Origin- und Referer-Header
• CSRF in SPAs und APIs
• CSRF in OAuth und SAML
• Clickjacking und UI-Redress (Kap 10)
• Cookies und LocalStorage (Kap 5)
• XSS-Grundlagen (Kap 11)