Was ist CSRF und wie verhindern Tokens und SameSite es?

Cross-Site Request Forgery (CSRF) nutzt eine Eigenheit des Webs aus: Browser hängen die Cookies einer Website automatisch an jede Anfrage an diese Website an, auch an Anfragen, die von einer anderen Website ausgelöst werden. Wenn ein Nutzer bei seiner Bank angemeldet ist und dann die Seite eines Angreifers besucht, kann diese Seite stillschweigend einen Formular-POST an die Bank absetzen — und der Browser fügt brav das Sitzungs-Cookie hinzu. Die Bank sieht eine authentifizierte Anfrage und führt die Überweisung aus. Der Angreifer liest nie eine Antwort; er braucht nur, dass die Aktion geschieht.

Warum die automatische Berechtigung die Ursache ist

CSRF funktioniert, weil die Authentifizierung automatisch erfolgt — belegt durch ein Cookie, das der Browser von selbst sendet, ohne Nachweis, dass die Anfrage tatsächlich von der legitimen Anwendung stammt. Abwehrmaßnahmen müssen daher ein Signal hinzufügen, dass diese Anfrage wirklich von unserer Anwendung kam.

Anti-CSRF-Tokens (Synchronizer-Muster)

Der Server bettet ein geheimes, sitzungsspezifisches, unvorhersehbares Token in seine eigenen Formulare ein und verlangt es bei jeder zustandsändernden Anfrage zurück. Die Cross-Origin-Seite eines Angreifers kann dieses Token nicht lesen (die Same-Origin Policy blockiert das Lesen der Antwort, die es enthält) und kann es nicht erraten. Die gefälschte Anfrage hat daher kein gültiges Token und wird abgelehnt.

SameSite-Cookies

Das SameSite-Cookie-Attribut teilt dem Browser mit, wann das Cookie gesendet werden soll:

• Strict — nie bei Cross-Site-Anfragen (am stärksten, kann aber eingehende Links zu angemeldeten Seiten zerstören).
• Lax — wird bei Top-Level-Navigationen (Klick auf einen Link) gesendet, aber nicht bei Cross-Site-POSTs oder Unterressourcen-Anfragen; ein sinnvoller Standard, der klassisches Formular-POST-CSRF blockiert.
• None — wird immer gesendet (erfordert Secure); nötig für legitime Cross-Site-Kontexte.

Das Zusammenspiel mit XSS

CSRF-Tokens setzen voraus, dass der Angreifer außerhalb der Website ist. Hat die Anwendung zusätzlich eine XSS-Lücke, läuft das eingeschleuste Skript im Origin und kann das Token lesen — XSS hebelt also den CSRF-Schutz aus. Beide müssen behoben werden.

Prüfer achten auf das automatische Senden von Cookies als Ursache, auf die an die Same-Origin Policy gebundene Unvorhersehbarkeit des Tokens, auf die Unterscheidung zwischen Lax und Strict sowie auf den XSS-Vorbehalt.