Cross-Site-Request-Forgery (CSRF)

Cross-Site Request Forgery (CSRF) bringt den Browser eines authentifizierten Benutzers dazu, nicht autorisierte Anfragen an eine Webanwendung zu senden. Der Browser sendet Cookies automatisch mit Anfragen, daher kann der Server legitime und gefälschte Anfragen ohne zusätzliche Maßnahmen nicht unterscheiden.

Szenario:

1. Das Opfer ist bei bank.com angemeldet (Sitzungscookie im Browser)
2. Das Opfer besucht die Seite des Angreifers mit: <img src="https://bank.com/transfer?to=attacker&amount=1000">
3. Der Browser sendet die GET-Anfrage mit dem angehängten Cookie von bank.com
4. Die Bank führt die Überweisung aus

CSRF über POST erfordert ein Formular:

Die wichtigste Abwehrmaßnahme ist ein CSRF-Token: ein zufälliger, geheimer Wert pro Sitzung oder pro Anfrage, der in Formulare eingebettet wird. Der Server validiert das Token bei jeder zustandsändernden Anfrage. Ein Angreifer auf einer anderen Domain kann das Token aufgrund der Same-Origin-Policy nicht auslesen.

SameSite=Strict: Das Cookie wird überhaupt nicht mit Cross-Site-Anfragen gesendet. SameSite=Lax: Das Cookie wird mit sicheren Top-Level-Navigationen (Links) gesendet, aber nicht mit POST-Anfragen von anderen Webseiten. Moderne Browser verwenden standardmäßig Lax, wodurch das CSRF-Risiko deutlich sinkt.

Eine Alternative zur serverseitigen Speicherung des Tokens: Setzen Sie ein zufälliges CSRF-Cookie und verlangen Sie, dass es zusätzlich als Anfrageparameter übermittelt wird. Ein Angreifer kann das Cookie nicht auslesen (Same-Origin), sodass er keinen passenden Wert in den Formulardaten angeben kann.

Bei AJAX-Anfragen bietet die Anforderung eines benutzerdefinierten Headers, beispielsweise X-Requested-With: XMLHttpRequest, Schutz vor CSRF, da Browser Cross-Origin-Skripte daran hindern, beliebige Header zu setzen (CORS erzwingt dies).

CSRF-Tokens sind wirkungslos, wenn:

• XSS vorhanden ist — der Angreifer kann das Token über JavaScript auslesen
• das Token in der URL offengelegt wird (Referer-Header)
• das Token vorhersehbar ist oder wiederverwendet wird
• CORS falsch konfiguriert ist und den Ursprung des Angreifers zulässt

Testschritte:

1. Zustandsändernde Anfragen identifizieren (POST, PUT, DELETE)
2. Das CSRF-Token entfernen oder ändern und die Anfrage erneut senden
3. Eine Cross-Origin-Formularübermittlung erstellen und prüfen, ob sie erfolgreich ist
4. Das SameSite-Attribut der Sitzungscookies überprüfen

REST-APIs, die JSON verwenden, sind häufig nicht anfällig für CSRF, wenn sie:

• Content-Type: application/json verlangen (HTML-Formulare können diesen Header nicht setzen)
• Token-basierte Authentifizierung verwenden (Authorization-Header statt Cookies)

APIs, die Cookies akzeptieren, müssen dennoch einen CSRF-Schutz implementieren.

Da SameSite=Lax in Chrome, Firefox und Safari standardmäßig aktiviert ist, werden viele traditionelle CSRF-Angriffe blockiert. Angriffe über Subdomains und bestimmte Navigationsmuster können Lax jedoch weiterhin umgehen. Kombinieren Sie SameSite mit CSRF-Tokens, um einen robusten Schutz zu erreichen.

Was ist die wichtigste Abwehrmaßnahme gegen CSRF-Angriffe in Webanwendungen?

CSRF nutzt das automatische Anhängen von Cookies durch den Browser aus, um authentifizierte Anfragen von bösartigen Webseiten zu fälschen. Die wichtigste Abwehrmaßnahme sind serverseitig validierte CSRF-Tokens. Eine zusätzliche Maßnahme ist das SameSite=Strict/Lax-Cookie-Attribut. APIs, die Token zur Authentifizierung in Headern statt in Cookies verwenden, sind von Natur aus gegen CSRF geschützt. Kombinieren Sie mehrere Schutzmaßnahmen; XSS kann vorhandene CSRF-Tokens umgehen.