Was ist CSRF (Cross-Site Request Forgery)?

Cross-Site Request Forgery (CSRF, auch XSRF oder Session Riding genannt) ist ein Web-Sicherheitsangriff, der einen angemeldeten Benutzer zwingt, eine unerwünschte Aktion auf einer Webanwendung auszuführen, in der er gerade authentifiziert ist. Der Angreifer präpariert einen schadhaften Link, ein Bild oder ein Formular auf einer Seite, die er kontrolliert. Besucht das Opfer diese Seite, während es noch auf der Zielseite eingeloggt ist (zum Beispiel Online-Banking, WordPress-Admin oder Webmail), sendet der Browser die Anfrage automatisch zusammen mit dem gültigen Session-Cookie. Der Server kann die gefälschte Anfrage nicht von einer echten unterscheiden und führt sie aus: Geld überweisen, E-Mail-Adresse ändern, Beitrag löschen, Adminrechte vergeben. CSRF stand in den OWASP Top 10 von 2007 und 2010 auf Platz 5, fiel 2017 aus der Top 10, weil große Frameworks eingebaute Schutzmechanismen einführten, und ist im OWASP Top 10 von 2021 als Kategorie unter A01 Broken Access Control gelistet. Der Samy-Wurm auf MySpace (Oktober 2005, über 1 Million infizierte Profile in 20 Stunden) ist der bekannteste CSRF-basierte Vorfall der Geschichte.

Wie funktioniert ein CSRF-Angriff?

Der Angreifer braucht drei Voraussetzungen:

1. Das Opfer ist auf der Zielseite eingeloggt (Cookie-basierte Session im Browser aktiv).
2. Die Zielseite führt zustandsändernde Aktionen allein aufgrund von Cookies aus, ohne zusätzliches Anti-CSRF-Token.
3. Das Opfer besucht eine vom Angreifer kontrollierte Seite oder öffnet eine entsprechende E-Mail.

Einfaches Beispiel: die Zielbank nutzt https://bank.example.de/transfer?to=KONTO&amount=1000 als GET-Anfrage. Der Angreifer bettet auf seiner Seite ein:

<img src="https://bank.example.de/transfer?to=ANGREIFER&amount=10000" width="0" height="0">

Der Browser lädt das Bild, sendet die Anfrage mit dem Session-Cookie des Opfers, die Bank führt die Überweisung aus. POST-Varianten nutzen ein verstecktes Formular mit Auto-Submit per JavaScript:

<form action="https://bank.example.de/transfer" method="POST" id="f">
  <input name="to" value="ANGREIFER">
  <input name="amount" value="10000">
</form>
<script>document.getElementById('f').submit();</script>

Typische CSRF-Ziele

• Banking und Zahlung: Überweisungen, Empfänger hinzufügen, PIN ändern.
• Webmail: Wiederherstellungs-E-Mail ändern, Weiterleitungsregel anlegen.
• Adminoberflächen: neuen Admin anlegen, Seiten-URL ändern, Plugin installieren.
• Soziale Netzwerke: Status posten, Freundschaftsanfragen senden (Samy-Wurm-Muster).
• E-Commerce: Lieferadresse kurz vor dem Checkout ändern.
• Router und IoT: viele Heimrouter bieten Adminoberflächen ohne CSRF-Schutz im LAN. Ein Angreifer kann DNS-Einstellungen über eine bösartige Seite ändern.

Wie unterscheidet sich CSRF von XSS?

XSS ist strikt mächtiger als CSRF. Ist eine Seite XSS-verwundbar, helfen CSRF-Schutzmechanismen nicht mehr, da das Angreifer-JavaScript den CSRF-Token aus dem DOM auslesen kann. XSS-Schutz ist damit Voraussetzung für jeden CSRF-Schutz.

Standard-Schutzmechanismen gegen CSRF

1. Anti-CSRF-Token (Synchronizer Token Pattern): der Server hängt ein zufälliges, unvorhersagbares Token in jedes HTML-Formular oder jede AJAX-Anfrage. Der Browser sendet es beim Absenden zurück und der Server prüft es. Die Angreifer-Seite kann den Token wegen der Same-Origin-Policy nicht lesen. Das ist der von OWASP empfohlene Primärschutz.
2. SameSite-Cookie-Attribut: ein Cookie, das nur bei Same-Site-Anfragen mitgesendet wird, ist gegen die meisten CSRF-Angriffe immun. Drei Werte: Strict (nie cross-site gesendet), Lax (bei Top-Level-Navigation gesendet, Default in Chrome seit Februar 2020), None (immer gesendet, muss mit Secure kombiniert werden). Session-Cookies auf SameSite=Lax oder Strict setzen stoppt die meisten CSRF-Angriffe.
3. Double Submit Cookie: der Server setzt einen zufälligen Wert in ein Cookie und der Client sendet ihn in einem eigenen Header zurück. Funktioniert ohne serverseitigen Session-State.
4. Origin- und Referer-Header prüfen: der Server vergleicht Origin- oder Referer-Header gegen die erwartete Domain. Sinnvolle Defense in Depth.
5. Custom Request Header für AJAX: ein Header wie X-Requested-With: XMLHttpRequest blockiert einfache Cross-Origin-Angriffe, weil Browser bei eigenen Headern einen CORS-Preflight erzwingen.
6. Re-Authentifizierung für kritische Aktionen: vor E-Mail-Wechsel, Konto-Löschung oder Überweisung erneut Passwort abfragen. Komfort-vs.-Sicherheit-Abwägung.
7. POST statt GET für Zustandsänderungen: GET sollte Zustand nie ändern. Image- und Link-Tags lösen GET aus, aber kein POST.

Was ist SameSite=Lax und warum ist es jetzt Standard?

Chrome erzwingt SameSite=Lax seit Februar 2020 (Chrome 80) als Default für Cookies ohne explizites Attribut, Firefox folgte im August 2020 (Firefox 79), Safari setzt seit 2018 eine noch strengere ITP-basierte Policy durch. Lax bedeutet: Cookie wird bei Top-Level-Navigation (Klick auf Link) gesendet, aber nicht bei Cross-Site-Sub-Requests (Bilder, iframes, XHR, Formularabsendungen an andere Origins). Diese eine Browser-Änderung hat den Großteil klassischer CSRF-Angriffe im offenen Web entschärft. Neue Cookies sollten SameSite trotzdem explizit setzen, weil der Default uneinheitlich durchgesetzt wird.

Wie schützt WordPress vor CSRF?

WordPress nutzt Nonces (Number used Once, trotz des Namens nicht strikt einmalig nutzbar). Ein Nonce ist ein kurzes Token, erzeugt aus Benutzersitzung, Zeit und Aktionsname. Kernfunktionen:

// Nonce für ein Formular erzeugen
<?php wp_nonce_field('delete_post_42', '_wpnonce'); ?>

// Oder als URL-Parameter
$url = wp_nonce_url(admin_url('options.php?action=delete&id=42'), 'delete_post_42');

// Oder als JavaScript-Konstante
wp_localize_script('my-script', 'myAjax', array(
    'nonce' => wp_create_nonce('my_ajax_action')
));

// Im Handler prüfen
check_admin_referer('delete_post_42');
// oder für AJAX
check_ajax_referer('my_ajax_action', 'nonce');

WordPress-Nonces haben eine Lebensdauer von 24 Stunden (geteilt in zwei 12-Stunden-Fenster, damit ein Nonce kurz vor Ablauf noch eine Runde valide ist). Sie sind nicht session-unique, aber durch die User-ID im Hash benutzerbezogen. Plugins mit eigenen Admin-Aktionen müssen Nonces nutzen, sonst entstehen CSRF-Lücken, die Bug-Bounty-Hunter und Wordfence Threat Intelligence regelmäßig als CVEs publizieren.

Was ist mit modernen Single-Page-Apps und REST-APIs?

SPAs, die Cookies zur Authentifizierung nutzen, brauchen weiterhin CSRF-Schutz, weil Cookies automatisch mitgesendet werden. Übliche Muster:

• SameSite=Strict auf dem Session-Cookie.
• Custom Header wie X-CSRF-Token bei jedem zustandsändernden API-Call. Der Server liefert den Token nach Login per GET, das Frontend speichert ihn im Speicher.
• Oder Authentifizierung auf Authorization: Bearer <JWT> umstellen. Tokens im JavaScript-Speicher werden vom Browser nicht automatisch angehängt, CSRF entfällt. Risiko verlagert sich zu XSS, daher wird eine strikte CSP Pflicht.

Bekannte CSRF-Vorfälle

• Samy-Wurm auf MySpace (Oktober 2005): CSRF + XSS Kombination, jeder Besucher eines infizierten Profils wurde selbst infiziert. Über 1 Million Profile in 20 Stunden. Samy Kamkar wurde zu Sozialstunden verurteilt.
• YouTube (2008): CSRF erlaubte das Hinzufügen beliebiger Videos zur Playlist eines Benutzers.
• Netflix (2006): CSRF erlaubte das Hinzufügen von Filmen zur Warteschlange.
• Zahlreiche WordPress-Plugins: hunderte CVEs pro Jahr wegen fehlender Nonces. 2024 betroffen waren unter anderem Forminator, LiteSpeed Cache, Royal Elementor Addons.
• Heimrouter: eine Studie 2018 fand CSRF in über 70 Prozent der Consumer-Router von Asus, Netgear, D-Link, was DNS-Hijack ermöglichte.

Wie hilft InspectWP bei CSRF?

InspectWP analysiert die Response-Header jeder gescannten URL und prüft Set-Cookie-Attribute inklusive SameSite und Secure. Cookies ohne SameSite-Attribut oder mit SameSite=None bei Session-Cookies werden im Sicherheitsbereich markiert.