Menu Close

Was ist Cross-Site Request Forgery?

In diesem Beitrag werden wir uns mit dem Angriff Cross-Site Request Forgery (CSRF) beschäftigen und erklären, wie man sich dagegen schützen kann.

Die Wurzel des Problems

Um Entwicklern zu helfen, die Geschwindigkeit ihrer Websites zu maximieren, laden sie ressourcenintensive Inhalte von anderen Domains (CDNs). Auf diese Weise ist die Website oder Anwendung mit einer anderen verbunden, und sie senden sich gegenseitig Anfragen, kommunizieren miteinander. Dies stellt kein Sicherheitsrisiko dar, solange dies ohne Anmeldung geschieht.

Wenn ein Benutzer in einer Anwendung angemeldet ist, sendet der Browser zusätzlich zur Anfrage Session-Cookies, die von Angreifern ausgenutzt werden können, um Anfragen zu fälschen.

Das folgende Beispiel illustriert das Problem. Wenn wir in der Web-Anwendung unsere E-Mail-Adresse ändern wollen, senden wir eine GET-Request an den Server, die wie folgt aussieht:

https://example.com/email/[email protected]

Der Server empfängt die Anfrage zusammen mit dem Cookie und führt sie aus. Das Problem beginnt damit, dass der Angreifer von dieser Anfrage Kenntnis hat und das Opfer dazu bringt, auf den Link zu klicken, den er mit seiner E-Mail-Adresse geändert hat:

https://example.com/email/[email protected]

Das Opfer klickt auf den Link (z.B. in einer E-Mail) und da es in die Anwendung eingeloggt ist, sendet der Browser das Cookie. Der Server betrachtet dies ebenfalls als eine gültige Anfrage und führt sie aus.
Nach einer solchen Änderung der E-Mail-Adresse veranlasst ein Angreifer in der Regel eine Passwortzurücksetzung und übernimmt die Kontrolle über die Anwendung und schließt den Nutzer aus.

Ein solcher Angriff ist in der Praxis nicht so einfach, da moderne Anwendungen POST-Anfragen verwenden, um wichtige Operationen durchzuführen. In solchen Fällen erstellt der Angreifer eine HTML-Seite, mit der er sein Opfer austricksen kann.

Schutz gegen CSRF

Die Verteidigung gegen Cross-Site-Request Forgery ist keine leichte Aufgabe, da anwendungsübergreifende Änderungen implementiert werden müssen. Alle Schnittstellen, die Änderungen vornehmen, müssen gesichert werden.

Der häufigste Schutzmechanismus ist ein sogenanntes (CSRF) Token, das die Anwendung mit jeder Anfrage sendet und serverseitig validiert. Wenn dieses Token zufällig genug ist, so dass der Angreifer nicht erraten oder vorhersagen kann, schützt es vor CSRF-Angriffen.

Eine andere Lösung heißt SameSite-Cookie, die dem Browser mitteilt, in welchen Fällen er das Session-Cookie an Anfragen anhängen soll.

Mehr um das Thema SameSite Cookies: https://web.dev/samesite-cookies-explained/

Relevante Dienstleistung: