Sessions, Cookies und CSRF-Schutz
Nach einer erfolgreichen Anmeldung wird die Sitzungskennung vorübergehend so wertvoll wie das Passwort. Sie muss zufällig, vertraulich, kurzlebig und gegen ungewollte browserseitige Aktionen geschützt sein.
Inhaltsverzeichnis
Sichere Session-Cookies
Secure: Übertragung nur über HTTPSHttpOnly: kein gewöhnlicher Zugriff durch JavaScriptSameSite: begrenzt Cross-Site-Übertragung entsprechend dem Anwendungsfall- enger Pfad und keine unnötig weite Domain
- angemessene Ablaufzeit und serverseitige Ungültigmachung
Speichern Sie Session-IDs oder Anmeldetokens nicht in URLs. Protokolle, Browserhistorie und Referrer können sie sonst weitergeben. Für klassische Sitzungen sind HttpOnly-Cookies in der Regel geeigneter als localStorage.
Nach der Anmeldung
- Erzeugen Sie eine neue Session-ID.
- Speichern Sie nur notwendige Sitzungsdaten serverseitig.
- Prüfen Sie Berechtigungen bei jeder geschützten Aktion.
- Beenden Sie die Sitzung serverseitig bei Abmeldung.
- Invalidieren Sie Sitzungen nach Passwort- oder Rollenänderungen, wenn erforderlich.
CSRF-Schutz
Verwenden Sie die gepflegte CSRF-Funktion des Frameworks. Zustandsändernde Aktionen gehören nicht in GET-Anfragen. Prüfen Sie bei POST, PUT, PATCH und DELETE ein unvorhersehbares, zur Sitzung passendes Token oder das dokumentierte Schutzverfahren des Frameworks.
SameSite ist eine zusätzliche Schutzschicht, aber nicht für jede Anwendung ein vollständiger Ersatz für CSRF-Tokens. XSS kann zahlreiche CSRF-Schutzmaßnahmen umgehen und muss separat verhindert werden.
