Broken Authentication
Broken Authentication (OWASP A07) bezeichnet eine Klasse von Schwachstellen rund um Authentifizierung und Session-Management: schwache Passwörter ohne Richtlinie, kein Schutz gegen Brute-Force, unsichere Passwort-Reset-Flows, schlecht konfiguriertes Session-Management. Das Ergebnis ist dasselbe wie bei jeder anderen Authentifizierungsschwäche: Ein Angreifer kann als ein anderer Nutzer auftreten.
Session-Management ist ein besonders fehleranfälliger Bereich. Nach dem Login erhält der Nutzer ein Session-Token – eine Art temporärer Ausweis, den er bei jeder Anfrage mitschickt. Ist dieses Token vorhersehbar, zu langlebig, nicht invalidierbar oder über unsichere Kanäle übertragbar, kann es gestohlen oder geraten werden. Der Angreifer braucht das Passwort dann nie – das Token reicht.
1) Typische Schwachstellen im Detail
Broken Authentication ist kein einzelner Fehler, sondern eine Kategorie von Implementierungsfehlern. Klicke auf eine Schwachstelle für Details, typisches Code-Beispiel und Gegenmaßnahme.
Credential Stuffing: Angreifer verwenden Passwortlisten aus anderen Datenlecks (rockyou.txt: 14 Mio Passwörter). Wenn Nutzer Passwörter wiederverwenden, ist ein Treffer wahrscheinlich.
Schutz: Rate-Limiting (max. 5–10 Versuche / Minute), Account-Lockout oder CAPTCHA nach Fehlversuchen, MFA, Abgleich gegen HaveIBeenPwned-API beim Passwort-Set.
Praxis-Bug:
session.destroy() wird nur client-seitig (Cookie löschen) ausgeführt, aber server-seitig bleibt die Session aktiv.Schutz: Server-seitige Session-Invalidierung bei Logout. Session-Ablaufzeiten erzwingen. Absolute Session-Lifetime (z.B. max. 24h), unabhängig von Aktivität.
https://app.de/dashboard?sessionid=abc123. Diese URL landet in Browser-History, Server-Logs, Proxy-Logs und im Referer-Header beim Weiterleiten auf externe Seiten.Schutz: Session-ID ausschließlich im Cookie speichern (
HttpOnly, Secure-Attribute). Nie in URLs, GET-Parametern oder HTML einbetten.
Schutz: Session-IDs kryptografisch zufällig generieren (min. 128 Bit Entropie). Niemals ableitbare IDs verwenden. Standard:
crypto.randomBytes(32) (Node.js), secrets.token_hex(32) (Python), Framework-Sessions (die das korrekt implementieren).
Schutz: Kryptografisch zufälliger Reset-Token (min. 128 Bit). Ablaufzeit: 15–30 Minuten. Einmalige Verwendung (Token nach Nutzung invalidieren). Keine Sicherheitsfragen. Nur per E-Mail an verifizierte Adresse senden.
Schutz: MFA für alle Konten, zwingend für Admin-Accounts. FIDO2/Passkeys als phishing-resistente Option. Technisch erzwingen – nicht nur empfehlen. Details: Authentifizierung und MFA.
2) Sichere Session-Token: schwach vs. stark
Ein gutes Session-Token ist kryptografisch zufällig, hat ausreichend Entropie, wird ausschließlich im Cookie gespeichert und hat eine begrenzte Lebensdauer. Die folgende Übersicht zeigt den Unterschied zwischen einem schwachen und einem starken Token-Design.
HttpOnly verhindert JavaScript-Zugriff (schützt vor XSS-Cookie-Diebstahl); Secure erzwingt HTTPS-Übertragung; SameSite=Lax schützt vor CSRF. Zusammen: Set-Cookie: session=TOKEN; HttpOnly; Secure; SameSite=LaxZusammenfassung
| Schwachstelle | Schutz |
|---|---|
| Kein Rate-Limiting | Max. 10 Fehlversuche/Min., CAPTCHA, Account-Lockout |
| Session nicht invalidiert | Server-seitige Invalidierung bei Logout + Ablauf |
| Session-ID in URL | Ausschließlich Cookie (HttpOnly, Secure, SameSite) |
| Vorhersehbare Session-IDs | crypto.randomBytes(32) oder Framework-Default |
| Unsicherer Passwort-Reset | Zufälliger Token, 30-min Ablauf, Einmalverwendung |
| Keine MFA | MFA für alle, zwingend für Admins. FIDO2 bevorzugt |