Cross-Site Request Forgery

Cross-Site Request Forgery (CSRF, gelegentlich auch XSRF oder Session Riding) ist eine Klasse von Angriffen auf Webanwendungen, bei der ein Angreifer den Browser eines authentifizierten Opfers dazu bringt, eine ungewollte, zustandsverändernde Anfrage an eine vertrauenswürdige Anwendung zu senden. Der entscheidende Hebel ist, dass der Browser automatisch alle relevanten Anmeldeinformationen — insbesondere Session-Cookies — an die Zieldomain mitschickt, sobald eine Anfrage dorthin ausgeht. Der Server kann dabei nicht ohne Weiteres unterscheiden, ob die Anfrage aus der legitimen Anwendung stammt oder von einer fremden, vom Angreifer kontrollierten Seite ausgelöst wurde.

Wie ein klassischer CSRF-Angriff abläuft

Das Lehrbuchbeispiel ist eine Online-Banking-Anwendung. Das Opfer ist bei seiner Bank unter bank.example eingeloggt und ruft in einem anderen Tab eine harmlos wirkende Seite auf, etwa einen Forenbeitrag oder eine Werbeanzeige. Diese Seite enthält ein verstecktes HTML-Formular, das per JavaScript automatisch an bank.example/transfer abgeschickt wird — mit Empfängerkonto und Betrag bereits ausgefüllt. Der Browser hängt das gültige Session-Cookie der Bank an, und die Überweisung wird im Namen des Opfers ausgeführt. Es ist kein Schadcode auf der Bankseite erforderlich und auch keine Schwachstelle in der Authentifizierung — ausgenutzt wird allein das Vertrauen des Servers in den eingehenden Cookie-Wert.

CSRF beschränkt sich nicht auf Banking. Jede zustandsverändernde Aktion ist potenziell betroffen: Passwortänderungen, E-Mail-Adresse aktualisieren, Rechte vergeben, Datensätze löschen, Einkäufe abschließen. Auch Admin-Oberflächen interner Anwendungen oder Router-Webinterfaces sind klassische Ziele, gerade weil dort GET-Requests oft direkt Konfigurationsänderungen auslösen.

Schutzmaßnahmen

Wirksame Verteidigung gegen CSRF setzt auf mehreren Ebenen an: ein nicht-vorhersagbares Token, das die fremde Seite nicht kennen kann, restriktive Cookie-Attribute, die das automatische Mitsenden von Sitzungs-Cookies bei Cross-Site-Requests verhindern, sowie Origin-Prüfungen auf Server-Seite. In modernen Anwendungen kombiniert man diese Mechanismen typischerweise.

Synchronizer-Token-Pattern

Die etablierte Schutzmaßnahme ist das Synchronizer-Token-Pattern, oft CSRF-Token genannt. Der Server generiert pro Session (oder pro Anfrage) einen kryptografisch zufälligen Wert, bettet ihn in jedes Formular als verstecktes Feld ein und prüft bei jeder zustandsverändernden Anfrage, ob das mitgesendete Token mit dem in der Session hinterlegten übereinstimmt. Eine fremde Seite kennt das Token nicht und kann es wegen der Same-Origin-Policy auch nicht auslesen — der Angriff schlägt fehl. Moderne Web-Frameworks wie Django, Laravel, Spring oder Ruby on Rails liefern dieses Pattern standardmäßig mit.

Double-Submit-Cookie

Beim Double-Submit-Cookie wird das Token sowohl in einem Cookie als auch im Request-Body oder Header mitgeschickt. Der Server vergleicht beide Werte. Eine fremde Seite kann das Cookie zwar mitsenden lassen, aber nicht auslesen und nicht zusätzlich in den Body schreiben. Das Verfahren ist besonders für zustandslose APIs attraktiv, weil es keinen Server-State erfordert — allerdings sollte das Cookie signiert oder mit dem Body kryptografisch verknüpft sein, um Subdomain-Übernahmen abzufangen.

SameSite-Cookies

Das SameSite-Attribut auf Cookies ist die wirksamste strukturelle Maßnahme der letzten Jahre. Mit SameSite=Strict sendet der Browser das Cookie ausschließlich bei Anfragen, deren Ursprung mit der Zieldomain übereinstimmt — Cross-Site-Requests bekommen das Cookie nicht. SameSite=Lax lockert das für Top-Level-Navigation per GET (etwa Klicks auf einen Link), was die meisten Anmeldeflüsse nicht stört. Seit Chrome 80 (Anfang 2020) gilt Lax als Browser-Default, wenn das Attribut fehlt. Damit ist eine ganze Klasse trivialer CSRF-Angriffe in der Praxis verschwunden.

Origin- und Referer-Prüfung

Server können den Origin- oder Referer-Header eingehender Anfragen mit der erwarteten eigenen Domain abgleichen. Bei Browsern, die diese Header zuverlässig setzen, ist das eine günstige Zusatzhürde. Sie ersetzt aber kein Token, weil Referer-Header in manchen Konstellationen unterdrückt werden und Proxies sie entfernen können.

Custom Header für AJAX

JavaScript-APIs, die nur über Custom Header wie X-Requested-With aufgerufen werden können, sind durch die CORS-Mechanik geschützt: Ein Cross-Origin-Request mit einem solchen Header löst einen Preflight aus, der ohne explizite Server-Freigabe fehlschlägt. Eine fremde Seite kann den Request damit gar nicht erst absenden.

Vergleich der Verfahren

CSRF in der OWASP Top 10

CSRF war in der OWASP Top 10 von 2013 als A8 gelistet. In der Liste 2017 wurde es entfernt, weil verbreitete Web-Frameworks zu diesem Zeitpunkt standardmäßig Token-Schutz mitlieferten und CSRF in Audits seltener gefunden wurde. Die Schwachstelle ist damit nicht verschwunden — sie taucht regelmäßig auf, sobald Teams eigene Frameworks bauen, REST-APIs ohne Cookie-Authentifizierung mit Cookie-Authentifizierung mischen oder ältere Anwendungen pflegen, in denen die Standardschutzmechanismen abgeschaltet wurden.

Moderne Sonderfälle

Mit SameSite=Lax als Browser-Default ist die Lage entspannt, aber nicht restlos gelöst. Zustandsverändernde GET-Endpunkte sind weiterhin angreifbar, weil Lax Top-Level-GETs durchlässt — eine Anwendung, die /account/delete per GET implementiert, ist anfällig, sobald ein Opfer auf einen präparierten Link klickt. Auch Top-Level-POSTs sind weiterhin möglich, wenn das Cookie explizit auf SameSite=None; Secure gesetzt ist, was bei kontextübergreifenden Integrationen (Drittanbieter-Widgets, eingebettete Dashboards) regelmäßig nötig ist. Login-CSRF — der Angreifer zwingt das Opfer in eine vom Angreifer kontrollierte Session — bleibt ebenfalls relevant, selbst wenn Geld- oder Datenflüsse durch SameSite geschützt sind.

In Kombination mit XSS verlieren CSRF-Token ihre Schutzwirkung: Schadcode im selben Origin kann das Token auslesen und beliebige Anfragen senden. Wir finden in Assessments deshalb regelmäßig Konstellationen, in denen CSRF-Schutz korrekt implementiert ist, aber durch eine separate XSS-Lücke ausgehebelt wird. CSRF-Härtung und XSS-Härtung gehören zusammen.

Relevanz für KMUs

Für mittelständische Unternehmen ist CSRF überall dort ein Thema, wo eigene Webanwendungen, Kundenportale, Admin-Oberflächen oder ältere Branchensoftware mit Webfrontend betrieben werden. Solange ein etabliertes Framework eingesetzt und nicht aktiv ausgeschaltet wird, ist das Grundrisiko niedrig. Kritisch wird es bei selbstgebauten Endpunkten, bei API-Gateways, die Cookies und Bearer-Token vermischen, sowie bei internen Tools, die seit Jahren ohne Review im Einsatz sind. In der Praxis prüfen wir bei einer Schwachstellenprüfung den korrekten Sitz und die Verifikation von CSRF-Token, die SameSite-Konfiguration aller Session- und Auth-Cookies sowie das Verhalten zustandsverändernder Endpunkte unter Cross-Origin-Bedingungen. Ergänzend liefert eine Web Application Firewall eine zweite Linie, ersetzt aber nie die saubere Implementierung in der Anwendung selbst.