CSRF: Cross-Site Request Forgery einfach erklärt

CSRF (Cross-Site Request Forgery, deutsch „Site-übergreifende Anfragenfälschung") ist ein Angriff, bei dem ein Angreifer einen eingeloggten Nutzer dazu bringt, ungewollt eine Aktion auf einer fremden Website auszuführen. Das Opfer merkt nichts davon — der Browser sendet die Anfrage automatisch mit, weil die Session und das Cookie noch gültig sind.

Wie ein CSRF-Angriff abläuft

Beispiel: Online-Banking
1. Du bist bei deiner Bank eingeloggt (Session-Cookie aktiv)
2. Du öffnest parallel eine bösartige Website oder eine präparierte E-Mail
3. Die Seite enthält ein unsichtbares Formular oder Bild, das eine Überweisung auslöst
4. Dein Browser sendet die Anfrage MIT deinem gültigen Session-Cookie
5. Die Bank denkt: „Der Nutzer will das" — und führt die Überweisung aus

Der Angriff funktioniert, weil Websites nicht automatisch prüfen können, ob eine Anfrage wirklich vom Nutzer gewollt war. Der Browser schickt Cookies bei jeder passenden Anfrage mit — auch bei Bildern, Formularen oder eingeschleusten Inhalten von Drittanbietern.

CSRF vs. XSS

Bei XSS (Cross-Site Scripting) schleust der Angreifer Code in die Seite ein und stiehlt z. B. Session-Daten. Bei CSRF nutzt der Angreifer die bereits bestehende Sitzung des Opfers, um Aktionen auszulösen. Beide Angriffe lassen sich kombinieren.

Schutzmaßnahmen

  • CSRF-Token: Jedes Formular enthält ein geheimes, zufälliges Token, das der Server beim Absenden prüft. Ein Angreifer kann es nicht mitliefern, weil er die Seite des Opfers nicht lesen kann.
  • SameSite-Cookies: Das Cookie-Attribut SameSite=Lax oder Strict verhindert, dass Cookies bei Cross-Site-Anfragen mitgesendet werden.
  • Benutzeraktion bestätigen: Bei kritischen Aktionen (Überweisung, Passwortänderung) zusätzlich Passwort oder 2FA abfragen.
  • Prüfen statt vertrauen: Der Server sollte bei Zustandsänderungen (POST) immer prüfen, ob die Anfrage vom eigenen Formular stammt.

Praxis-Tipps

  • Als Nutzer: Wichtig ist Phishing-Wachsamkeit — Links in unerwarteten E-Mails nicht blind öffnen.
  • Als Entwickler: Framework-Schutz aktivieren (z. B. CSRF-Middleware in Laravel, Django, Spring Security) und niemals Formulare ohne Token ausliefern.
  • Die Kommunikation sollte immer über HTTPS laufen, damit Token und Sessions nicht im Klartext über das Netz gehen.

Verwandte Grundlagen: XSS, Session, Cookies, Phishing, SSO, Zero Trust.