Stell dir vor, jemand lockt einen Besucher dazu, auf einen Link zu klicken, während er in sein Online-Banking eingeloggt ist. Der Link führt zu einem versteckten Formular, das ohne Wissen des Besuchers bei der Bank eine Überweisung auslöst. Die Bank sieht eine scheinbar legitime Anfrage eines angemeldeten Nutzers und führt sie aus. Der Angreifer hat nun Geld über das Konto des Opfers bewegt, ohne je dessen Passwort zu kennen.
Das ist CSRF (Cross-Site Request Forgery): ein Angriff, bei dem ein Angreifer ein Opfer dazu bringt, unbemerkt ein Formular oder eine Anfrage an eine andere Website zu senden, bei der das Opfer bereits angemeldet ist.
Das lernst du hier: Was CSRF-Angriffe sind und wie sie funktionieren, warum sie selbst bei anderen Schutzmaßnahmen so gefährlich sind, wie CSRF-Token sie verhindern und wie du deine Formulare schützt.
Was ist CSRF?
CSRF steht für Cross-Site Request Forgery, auf Deutsch etwa „websiteübergreifende Anfragenfälschung“. Der Angreifer nutzt aus, dass dein Browser deine Sitzung automatisch mit jeder Anfrage an eine Website mitschickt, bei der du angemeldet bist, selbst wenn die Anfrage von einer ganz anderen Website kommt.
Der Angriff funktioniert so: Ein angemeldeter Besucher wird dazu gebracht, unbemerkt ein Formular an eine Website zu senden, bei der er ein Konto hat. Das Passwort des Opfers kann der Angreifer nicht sehen. Er braucht es auch nicht. Er braucht nur, dass das Opfer bereits angemeldet ist, und löst dann eine Anfrage aus (zum Beispiel über ein verstecktes Formular), die etwas bewirkt, was der Angreifer will.
CSRF unterscheidet sich von anderen Angriffen, weil er weder Zugangsdaten stiehlt noch Verschlüsselung knackt. Er nutzt das Vertrauen aus, das die Website dem Opfer entgegenbringt. Das Opfer ist bereits authentifiziert, also vertraut die Website Anfragen, die von ihm zu kommen scheinen.
So funktionieren CSRF-Angriffe
Ein CSRF-Angriff läuft in drei Schritten ab.
Schritt 1: Das Opfer ist auf deiner Website angemeldet
Jemand besucht deine Website und meldet sich in seinem Konto an. Sein Browser hat nun ein aktives Sitzungs-Cookie, das beweist, dass er authentifiziert ist. Diese Sitzung bleibt aktiv, solange er die Website weiter nutzt.
Schritt 2: Der Angreifer lockt das Opfer auf eine schädliche Seite
Während er noch auf deiner Website angemeldet ist, besucht das Opfer eine Seite, die der Angreifer kontrolliert (etwa über einen Link aus sozialen Netzwerken, eine irreführende Anzeige oder eine Website, die seriös wirkt). Auf dieser Seite liegt versteckter Code, der ein Formular an deine Website sendet.
Schritt 3: Das Formular wird automatisch mit der Sitzung des Opfers abgeschickt
Das versteckte Formular wird an deine Website gesendet. Weil das Opfer bereits angemeldet ist, schickt sein Browser das Sitzungs-Cookie automatisch mit. Aus Sicht deines Formulars ist das eine legitime Anfrage eines authentifizierten Nutzers. Das Formular verarbeitet sie, als hätte das Opfer sie absichtlich abgeschickt.
Der Angreifer hat damit etwas auf deiner Website über das Konto des Opfers ausgelöst, ohne dass das Opfer es weiß. Vielleicht wurde das Passwort geändert, Geld überwiesen, ein Profil aktualisiert oder es wurden Daten gesendet.
Warum das auch bei anderen Schutzmaßnahmen funktioniert
CSRF-Angriffe umgehen mehrere gängige Sicherheitsfunktionen:
HTTPS stoppt CSRF nicht. Die Daten sind unterwegs verschlüsselt, aber der Angreifer muss sie gar nicht abfangen. Er schickt die Anfrage einfach aus dem Browser des Opfers, dem die Website bereits vertraut.
Passwortschutz stoppt CSRF nicht. Der Angreifer braucht das Passwort des Opfers nie. Er nutzt nur aus, dass das Opfer bereits angemeldet ist.
Ein starkes Login-System stoppt CSRF nicht. Selbst wenn die Authentifizierung perfekt ist, funktioniert der Angriff, sobald das Opfer angemeldet ist.
Deshalb ist CSRF-Schutz eine eigene Schutzebene. Andere Sicherheitsmaßnahmen verhindern ihn nicht. Du musst Formulare gezielt so gestalten, dass sie CSRF-Angriffen standhalten.
CSRF-Token: so stoppen sie den Angriff
Die Lösung ist ein CSRF-Token. Das ist eine einmalige, nicht vorhersagbare Zeichenfolge, die dein Server für jedes Formular erzeugt. So funktioniert es:
Dein Server erzeugt für jeden Besucher ein eigenes Token
Wenn jemand eine Seite mit einem Formular lädt, erzeugt dein Server ein zufälliges Token und verknüpft es mit der Sitzung dieses Nutzers. Das Token ist jedes Mal anders und gehört nur zu diesem Nutzer.
Das Token steckt im Formular
Das Token ist als verstecktes Feld im HTML-Formular enthalten. Schickt der Besucher das Formular ab, wird das Token mitgesendet.
Dein Server prüft das Token, bevor er die Einsendung verarbeitet
Wird das Formular abgeschickt, prüft dein Server, ob das Token in der Einsendung mit dem Token übereinstimmt, das du für die Sitzung dieses Nutzers erzeugt hast. Wenn ja, wird das Formular verarbeitet. Wenn nein (oder wenn kein Token da ist), wird es abgelehnt.
Das versteckte Formular des Angreifers kann kein gültiges Token enthalten, weil Token nicht vorhersagbar und für jede Sitzung einzigartig sind. Ein Angreifer auf einer anderen Domain kann das Token weder sehen noch erraten. Sein Angriff scheitert also. Das versteckte Formular wird zwar abgeschickt, aber dein Server lehnt es ab, weil das Token nicht passt.
So sieht ein CSRF-Token in der Praxis aus
In HTML sieht ein Formular mit CSRF-Schutz so aus:
<form method="POST" action="/submit-form"> <input type="hidden" name="csrf_token" value="a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6"> <input type="email" name="email" placeholder="Deine E-Mail"> <button type="submit">Absenden</button> </form>Das Feld `csrf_token` ist versteckt. Der Besucher sieht es nicht, aber es wird zusammen mit seinen Formulardaten gesendet. Dein Server prüft es, bevor er die E-Mail-Adresse oder andere Daten verarbeitet.
CSRF-Schutz für verschiedene Formulartypen
Klassische HTML-Formulare
Standard-HTML-Formulare (die Daten per POST an deinen Server senden) brauchen CSRF-Token. Dazu gehören Kontaktformulare, Login-Formulare, Formulare zum Zurücksetzen des Passworts und jedes Formular, das Daten auf deinem Server ändert.
AJAX- und JavaScript-Formulare
Auch Formulare, die per JavaScript an einen API-Endpunkt gesendet werden, brauchen CSRF-Schutz. Das Token kann im Formular selbst stehen, in einem Cookie gespeichert sein oder vor dem Senden aus einem Meta-Tag gelesen werden.
Zustandslose API-Anfragen
Nutzt deine API tokenbasierte Authentifizierung (wie JWT), funktioniert der CSRF-Schutz anders. Der Browser hängt ein JWT-Token nicht automatisch an wie ein Sitzungs-Cookie, daher ist klassisches CSRF hier eine geringere Gefahr. Trotzdem gilt als bewährte Praxis, ein zusätzliches CSRF-Token für mehr Schutz einzubauen.
Weitere Schutzmaßnahmen neben CSRF-Token
CSRF-Token sind die wichtigste Verteidigung, wirken aber am besten zusammen mit anderen Sicherheitsmaßnahmen.
SameSite-Cookies
Wenn du ein Sitzungs-Cookie setzt, kannst du das Attribut `SameSite` ergänzen. Es sagt dem Browser, das Cookie nicht mitzusenden, wenn die Anfrage von einer anderen Domain kommt. So kann das versteckte Formular des Angreifers die Sitzung des Opfers gar nicht erst nutzen.
Prüfung des Referer-Headers
Dein Server kann den Referer-Header prüfen, um zu sehen, woher die Anfrage kam. Behauptet eine Einsendung, von deiner Domain zu kommen, der Referer zeigt aber eine andere Domain, handelt es sich wahrscheinlich um einen Angriff. (Referer-Header lassen sich allerdings fälschen, daher ist das kein vollständiger Schutz.)
Double-Submit-Cookie-Muster
Bei diesem Ansatz wird das CSRF-Token sowohl in einem Cookie als auch in einem Formularfeld gespeichert. Dein Server prüft vor der Verarbeitung, ob beide übereinstimmen. Das ist seltener als klassische Token, funktioniert aber gut bei zustandslosen Anwendungen.
So setzt du CSRF-Schutz um
Die Details hängen von deinem Technologie-Stack ab, aber das Muster ist immer gleich:
- Erzeuge pro Sitzung ein eindeutiges Token. Wenn ein Nutzer eine Sitzung beginnt oder eine Formularseite lädt, erzeugt dein Backend ein neues Token.
- Speichere das Token auf dem Server. Hinterlege es zusammen mit der Sitzung dieses Nutzers.
- Binde das Token ins Formular ein. Füge es als verstecktes Feld im HTML oder als Meta-Tag ein, das JavaScript lesen kann.
- Prüfe beim Absenden. Bevor du Formulardaten verarbeitest, kontrolliere, dass das gesendete Token mit dem gespeicherten Token der Sitzung übereinstimmt.
- Erzeuge es nach sensiblen Aktionen neu. Ändert ein Nutzer sein Passwort oder tut etwas Kritisches, erzeuge ein neues Token.
Die meisten modernen Web-Frameworks erzeugen und prüfen CSRF-Token automatisch. Nutzt du ein Framework, ist der CSRF-Schutz meist standardmäßig eingeschaltet. Achte nur darauf, ihn nicht versehentlich auszuschalten.
Häufige Fehler, die Formulare angreifbar machen
CSRF-Schutz aus Bequemlichkeit abschalten. Manche Entwickler schalten CSRF-Prüfungen aus, um API-Tests zu erleichtern oder ihren Code zu vereinfachen. Tu das nicht. Es schafft eine echte Schwachstelle.
Ein statisches Token für alle Nutzer verwenden. Das Token muss zur Sitzung des jeweiligen Nutzers gehören. Ein Token, das für alle gleich ist (oder für alle Nutzer an allen Tagen), schützt nicht vor CSRF.
Token nicht erneuern. Verwendest du dasselbe Token wochenlang, hat ein Angreifer mehr Zeit, es auszunutzen. Erneuere Token regelmäßig und immer nach sensiblen Vorgängen.
Sich nur auf SameSite-Cookies verlassen. SameSite hilft, reicht aber nicht aus. Nutze CSRF-Token als Hauptverteidigung und SameSite als Absicherung.
Token bei manchen Formularen vergessen. Schützt du einige Formulare mit Token und andere nicht, nutzen Angreifer die ungeschützten. Jedes Formular, das Daten verändert, braucht Schutz.
Was WEMASY für den CSRF-Schutz tut
Die Formulare von WEMASY enthalten bei jedem Formular, das du erstellst, automatisch einen CSRF-Token-Schutz. Du musst nichts einrichten und nicht daran denken. Sendet ein Besucher ein Formular ab, prüft WEMASY das Token, bevor die Einsendung gespeichert wird. Dieser Schutz ist fest eingebaut und standardmäßig aktiv.
Mehr zu den Sicherheitsoptionen für Formulare findest du auf der Preisseite.