CSRF-Token (Anti-CSRF-Token)
CSRF-Token ist ein zufälliger, unvorhersehbarer Wert im Formular, der bei jedem Request validiert wird. Browser sendet ihn NICHT automatisch mit (im Gegensatz zu Cookies). Standard-Schutz gegen CSRF.
detaillierte erklärung
CSRF-Token ist ein kryptographisch zufälliger Wert (128+ Bit), der CSRF-Angriffe verhindert. Mechanismus: 1) Server generiert Token bei Session-Start, speichert in Session. 2) Token wird in Formular als Hidden-Field eingebettet (<input type="hidden" name="csrf_token" value="abc123">). 3) Bei Formular-Submit sendet Browser Token als POST-Parameter (NICHT als Cookie). 4) Server vergleicht POST-Token mit Session-Token - Match = legitim, Mismatch = CSRF-Angriff. Warum funktioniert das? Angreifer kann zwar Formular auf eigener Site erstellen, kennt aber Token nicht (Same-Origin-Policy verhindert JavaScript-Zugriff auf fremde Seiten). Varianten: Synchronizer-Token (in Session), Double-Submit-Cookie (Token in Cookie + Request-Parameter), Per-Request-Token (neues Token für jeden Request). Best-Practice: Token pro Session, HTTPS-Only, kurze Timeouts.
warum ist das wichtig?
CSRF-Token ist die bewährte CSRF-Abwehr - du musst verstehen, warum Token NICHT im Cookie sein darf (wird automatisch gesendet) und wie Double-Submit funktioniert. Essentiell für Web-Framework-Konfiguration (Django, Rails, Spring).
häufige fehler
- ⚠CSRF-Token im Cookie speichern reicht - Nein, Cookie wird automatisch gesendet (gleicher Angriff möglich), muss als POST-Parameter kommen
- ⚠Token muss geheim sein - Teils falsch, muss nur unvorhersehbar sein (selbst wenn Angreifer altes Token sieht, kann er neue nicht erraten)
- ⚠Jede Seite braucht eigenes Token - Nein, Session-basiertes Token reicht (einfacher), Per-Request ist strenger aber komplexer