Session-Management-Reviewer

Das Problem

Session-Management ist der Punkt, an dem Authentifizierung auf reale Komplexitaet trifft. Sessions, die nie ablaufen, geben Angreifern unbegrenzt Zeit, gestohlene Cookies auszunutzen. Mit schwacher Zufaelligkeit generierte Session-IDs koennen vorhergesagt werden. Session-Fixation-Angriffe ermoeglich es Angreifern, eine bekannte Session-ID vor der Authentifizierung zu setzen. Ohne korrekte Cookie-Flags lecken Session-Tokens durch XSS, unsichere Netzwerke oder Cross-Site-Requests.

Der Prompt

Du bist ein Session-Sicherheitsspezialist. Pruefe die Session-Management-Implementierung meiner Anwendung auf Schwachstellen.

SESSION-IMPLEMENTIERUNG:
- Typ: [z.B. serverseitige Sessions mit Redis, JWT in Cookies, verschluesselte Cookies]
- Framework: [z.B. Express + express-session, Django Sessions, Next.js]
- Cookie-Config: [Cookie-Einstellungen einfuegen — Name, Flags, Domain, Path, Ablauf]
- Session-Store: [z.B. Redis, Datenbank, Memory, Dateisystem]

CODE:
[Session-Erstellung, Validierung, Zerstoerung und Cookie-Konfiguration einfuegen]

Diese Session-Sicherheitsaspekte pruefen:

1. **Session-ID-Entropie**: Kryptografische Zufaelligkeit (128+ Bit)?
2. **Cookie-Flags**: HttpOnly, Secure, SameSite=Strict/Lax, korrekter Domain/Path-Scope?
3. **Session-Fixation**: Neue Session-ID nach Login?
4. **Inaktivitaets-Timeout**: Session-Ablauf nach Inaktivitaet?
5. **Absoluter Timeout**: Maximale Session-Lebensdauer unabhaengig von Aktivitaet?
6. **Gleichzeitige Sessions**: Koennen Nutzer aktive Sessions auf anderen Geraeten sehen und widerrufen?
7. **Session-Widerruf**: Koennen Sessions serverseitig invalidiert werden?
8. **Logout-Vollstaendigkeit**: Zerstoert Logout die Session auf dem Server UND loescht den Cookie?
9. **Session-Bindung**: Ist die Session an Client-Attribute gebunden (IP, User-Agent)?
10. **Cookie-Benennung**: Verraet der Cookie-Name die Technologie nicht?

Fuer jeden Befund Risikostufe und sicheren Implementierungscode bereitstellen.

Beispielausgabe

## Session-Review: 4 Befunde

### HOCH: Session-Cookie fehlt HttpOnly-Flag
Zeile 12: cookie: { httpOnly: false }
Risiko: Jede XSS-Schwachstelle kann den Session-Cookie ueber document.cookie stehlen.
Loesung: httpOnly: true setzen.

### HOCH: Keine Session-Regeneration nach Login
Session-ID bleibt vor und nach der Authentifizierung gleich.
Risiko: Session-Fixation — Angreifer setzt Cookie, Opfer loggt sich ein, Angreifer hat authentifizierte Session.
Loesung: req.session.regenerate() unmittelbar nach erfolgreicher Authentifizierung aufrufen.

Wann verwenden

Session-Management bei der Implementierung von Authentifizierung, beim Wechsel des Session-Storage-Backends oder bei Aenderung von Cookie-Richtlinien pruefen. Unverzichtbar nach Sicherheitsvorfaellen mit Session-Hijacking. Vor dem Produktions-Deployment ausfuehren.

Profi-Tipps

• Session-ID bei Privilegienaenderung regenerieren — nach Login, Rollenerhoehung oder jeder Privilegienaenderung neue Session-ID generieren.
• Inaktivitaets- UND absolute Timeouts implementieren — Inaktivitaets-Timeout laesst inaktive Sessions ablaufen, absoluter Timeout begrenzt auch aktive Sessions. Beide sind noetig.
• Serverseitiger Widerruf ist Pflicht — den Cookie clientseitig loeschen reicht nicht. Der Server muss die Session im Store ebenfalls invalidieren.
• Session-Anomalien ueberwachen — loggen, wenn eine Session von einer neuen IP oder einem neuen User-Agent verwendet wird.