Session-Management prüfen: Cookies, Timeouts und Logout

Sobald sich ein Benutzer angemeldet hat, ist die Session-ID vorübergehend gleichwertig mit dem stärksten Authentifizierungsverfahren, das die Anwendung verwendet hat, ob Passwort, Einmalcode, Client-Zertifikat, Smartcard oder Fingerabdruck. Kann ein Angreifer diese ID erraten, abgreifen oder vorgeben, ist er der Benutzer, und das Login-Formular spielt dabei keine Rolle mehr. Sessions zu testen bedeutet daher, die ID zu prüfen, das Cookie, das sie transportiert, und das Verhalten des Servers beim Login, nach Inaktivität und beim Logout.

Diese Checkliste orientiert sich am OWASP Session Management Cheat Sheet und an RFC 6265, der Cookie-Spezifikation.

Die Session-ID selbst

Beginnen Sie damit, wie die ID erzeugt wird. Das Cheat Sheet verlangt mindestens 64 Bit Entropie aus einem kryptografisch sicheren Zufallszahlengenerator. Bei dieser Größe schätzt es den Aufwand, eine gültige ID zu erraten, auf rund 585 Jahre, unter der Annahme von 10.000 Versuchen pro Sekunde und 100.000 gleichzeitig gültigen Sessions. Wenn Sie IDs selbst erzeugen, statt den Generator des Frameworks zu nutzen, empfiehlt es mindestens 128 Bit und einen eindeutigen Wert pro Session.

Achten Sie auf feste oder vorhersagbare Anteile. Eine hexadezimale ID mit 16 Zeichen, von der die Hälfte fest ist, hat nur 32 Bit Entropie, und das reicht nicht aus. Der Wert sollte für den Client außerdem keinerlei Bedeutung haben: keine Benutzer-ID, keine Rolle, keine E-Mail-Adresse darin. Diesen Zustand halten Sie auf dem Server.

Prüfen Sie auch den Namen. Standardnamen wie PHPSESSID, JSESSIONID, CFID/CFTOKEN und ASP.NET_SessionId verraten einem Angreifer, welchen Stack Sie einsetzen. Das Cheat Sheet schlägt einen generischen Namen wie id vor.

Akzeptieren Sie die ID niemals in einer URL. IDs in URLs gelangen über Links, Logs, Browserverlauf, Lesezeichen, den Referer-Header und Suchmaschinen nach außen und erleichtern Fixation-Angriffe.

Wenn Lesezugriff auf Ihren Session-Speicher zu Ihrem Bedrohungsmodell gehört, sind Klartext-Tokens ein Risiko. Das Cheat Sheet beschreibt ein geteiltes Design: Das Cookie enthält einen Identifier und einen geheimen Verifier, der Server speichert den Identifier und den SHA-256-Hash des Verifiers und vergleicht ihn in konstanter Zeit. Der Identifier allein wird nie akzeptiert.

Cookie-Attribute

RFC 6265 definiert für einen Set-Cookie-Header diese Attribute: Expires, Max-Age, Domain, Path, Secure und HttpOnly.

• Secure kennzeichnet das Cookie für sichere Verbindungen. Der RFC weist darauf hin, dass es gegen einen aktiven Angreifer im Netzwerk keine Integrität bietet. Betrachten Sie es also nicht als Schutz davor.
• HttpOnly gehört an jedes Session-Cookie. Prüfen Sie das Flag in den Entwicklertools des Browsers.
• Domain und Path legen den Geltungsbereich fest. Halten Sie beide nicht weiter, als die Anwendung es braucht.
• Expires und Max-Age teilen dem Browser mit, wie lange er das Cookie aufbewahren soll. Verwenden Sie sie nicht als Ihren Timeout.

Prüfen Sie die übrigen Response-Header mit unserem Security-Headers-Tool.

Login, Timeouts und Logout

Eine Session-ID, die der Browser schon vor dem Login hatte und danach behält, ist genau das, worauf Fixation-Angriffe aufbauen. Vergeben Sie bei der Authentifizierung eine neue ID, damit die frühere ungültig wird.

Timeouts brauchen zwei Grenzen. Ein Idle-Timeout beendet Sessions, die niemand nutzt. Ein absoluter Timeout beendet Sessions, die dauerhaft aktiv bleiben, und begrenzt so, wie lange eine gestohlene ID nützlich ist. Halten Sie die Werte schriftlich fest, wählen Sie sie kürzer für Administration und Zahlungen und setzen Sie sie auf dem Server durch, indem Sie den gespeicherten Session-Datensatz prüfen und nicht das Ablaufdatum des Cookies.

Das Logout muss die serverseitige Session zerstören. Das Cookie im Browser zu löschen reicht nicht, denn der Identifier ist die Zugangsberechtigung: Wer ihn zuvor kopiert hat, kann ihn weiterhin senden. Nach dem Logout sollte die alte ID auf nichts mehr verweisen. Das Cheat Sheet enthält außerdem einen Abschnitt zu Web-Content-Caching und Clear-Site-Data, der lesenswert ist, weil er zeigt, was der Browser nach dem Logout behält.

Nutzen Sie nach Möglichkeit die eingebaute Session-Verwaltung des Frameworks. Das Cheat Sheet merkt an, dass diese Implementierungen bereits Schwachstellen hatten. Setzen Sie daher die neueste Version ein und prüfen Sie die Standardeinstellungen.

Was zu testen ist

1. Erfassen Sie das Cookie vor und nach dem Login. Die erste Anfrage muss tatsächlich ein Session-Cookie setzen, prüfen Sie also, dass before.txt nicht leer ist. Legen Sie die Zugangsdaten in einer Datei ab (creds.txt mit dem Inhalt user=test&pass=...), damit sie nicht in der Shell-History landen. Die beiden IDs müssen sich unterscheiden.

curl -i -c before.txt https://app.example/login curl -i -b before.txt -c after.txt -d @creds.txt https://app.example/login

1. Melden Sie sich mit dem authentifizierten Cookie ab und senden Sie dann den alten Wert erneut, entnommen der letzten Spalte von after.txt. Er muss abgelehnt werden. Ist das Logout ein POST, ergänzen Sie beim ersten Befehl -d ''.

curl -i -b after.txt https://app.example/logout curl -i -b 'id=VALUE_FROM_AFTER_TXT' https://app.example/account

1. Melden Sie sich an, bleiben Sie über den Idle-Timeout hinaus inaktiv und senden Sie dann eine Anfrage. Sie muss erneut eine Authentifizierung verlangen.
2. Halten Sie eine Session über den absoluten Timeout hinaus aktiv. Sie muss trotzdem enden.
3. Prüfen Sie Set-Cookie in der Login-Antwort auf Secure, HttpOnly sowie Domain und Path, die nicht weiter gefasst sind als nötig.
4. Sammeln Sie einige hundert IDs und vergleichen Sie sie. Feste Segmente und fortlaufende Werte sind Findings. Gleichen Sie den Cookie-Namen mit den oben genannten Framework-Standardnamen ab.
5. Durchsuchen Sie Anwendung, Logs und Links nach Session-IDs in URLs.

Berichten Sie Findings gegen OWASP ASVS unter Angabe der Version: v5.0.0-<chapter>.<section>.<requirement>. ASVS 5.0.0 wurde am 30. Mai 2025 veröffentlicht, und seine Anforderungen liegen als CSV vor. Ergänzen Sie Ihr Testblatt um eine Spalte mit der Kennung für jeden Test, sodass ein fehlgeschlagener Test als Finding gelesen werden kann, das seine Anforderung benennt.

Wo Sie anfangen

1. Führen Sie zuerst die Tests 1 und 2 gegen die Staging-Umgebung durch: den ID-Vergleich vor und nach dem Login, danach den Replay nach dem Logout.
2. Erfassen Sie den Set-Cookie-Header Ihres Session-Cookies und korrigieren Sie fehlende oder zu weit gefasste Attribute.
3. Prüfen Sie, wie IDs erzeugt werden. Wenn Sie einen eigenen Generator gebaut haben, wechseln Sie zu dem des Frameworks oder stellen Sie sicher, dass er eine sichere Zufallsquelle mit mindestens 128 Bit nutzt.
4. Halten Sie Idle- und absoluten Timeout schriftlich fest, setzen Sie sie serverseitig durch und ergänzen Sie Tests, die fehlschlagen, falls jemand sie entfernt.
5. Sorgen Sie dafür, dass das Logout den serverseitigen Session-Datensatz löscht, und nehmen Sie die Replay-Tests in Ihre Regressionstests auf.