Wissen › Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF)
Das Opfer löst unbemerkt eine Aktion aus, weil der Request nicht an ein Token gebunden ist.
Bei Cross-Site Request Forgery bringt eine fremde Seite den Browser eines eingeloggten Opfers dazu, eine zustandsändernde Aktion auf der Zielanwendung auszulösen. Da der Browser die Session-Cookies automatisch mitschickt, wirkt die Aktion legitim — es fehlt der Nachweis, dass sie bewusst ausgelöst wurde.
Wie der Angriff funktioniert
- Das Opfer ist bei der Zielanwendung angemeldet (gültige Session im Cookie).
- Eine präparierte Seite sendet automatisch einen Request an die Zielanwendung (Formular-Autosubmit, Bild-URL …).
- Fehlt ein an die Session gebundenes, nicht erratbares Token, führt die Anwendung die Aktion aus.
Beispiel
Schützende Aktionen verlangen ein serverseitig geprüftes Token, das nur die eigene Seite kennt:
<!-- Fluid-Formular bindet das RequestToken automatisch ein -->
<f:form action="update" controller="Account" requestToken="true">
...
</f:form>Mögliche Auswirkungen
- Unbemerkte zustandsändernde Aktionen (Einstellungen ändern, Datensätze anlegen/löschen).
- Im Backend besonders kritisch (Rechte eines Redakteurs/Admins).
- Oft kombiniert mit XSS zur vollständigen Umgehung.
Worauf du in TYPO3 achten musst
TYPO3 schützt das Backend von Haus aus mit Tokens; im Frontend liefert der Core die Bausteine (RequestToken), die man in eigenen zustandsändernden Endpunkten einsetzen muss.
Backend ist tokengeschützt
Backend-Formulare und -Links tragen Tokens (FormProtection / moduleToken). Eigene Backend-Module sollen diese Mechanismen nutzen und nicht umgehen.
Frontend: RequestToken für zustandsändernde Aktionen
Ab TYPO3 v11 gibt es das RequestToken-Konzept. In Fluid-Formularen requestToken='true' setzen; serverseitig den nonce/HMAC prüfen, bevor die Aktion ausgeführt wird.
trustedProperties ist kein CSRF-Schutz
Extbase signiert mit trustedProperties zwar die erlaubten Felder (gegen Mass Assignment), schützt aber nicht gegen CSRF. Beides getrennt betrachten.
SameSite-Cookies als Basisschutz
Session-Cookies mit SameSite=Lax/Strict setzen (TYPO3 unterstützt die Konfiguration). Das entschärft viele Cross-Site-Requests, ersetzt aber Tokens nicht.
Zustandsänderungen nur per POST
GET-Requests dürfen nichts verändern. Lesende GETs sind harmlos; alles Schreibende über POST + Token.
Schutzmaßnahmen
- Zustandsändernde Aktionen an ein serverseitig geprüftes RequestToken binden.
- SameSite-Cookies, POST statt GET für Änderungen.
- Backend-Token-Mechanismen nutzen statt umgehen.