Skip to content
Pwnversity

Session Management

The session is the bridge between “I authenticated once” and “the server recognizes me on every request.” If that bridge is predictable, stealable, or never expires, the whole authentication is worthless: it doesn’t matter how strong the password is if the session identifier can be guessed, intercepted, or reused forever.

Threat model

Section titled “Threat model”

A session identifier is, in effect, a temporary credential. The attacker wins if they can: predict it (low entropy), capture it (XSS, no TLS, logs), fix it (session fixation), or keep using it after it should have died (logout/timeout that don’t invalidate server-side). The most common flaw isn’t cryptographic: it’s that the server trusts a token it never revokes.

Anatomy

Section titled “Anatomy”
Set-Cookie: session=4f8a...; HttpOnly; Secure; SameSite=Lax; Path=/

Cookie attributes are half the defense. Without HttpOnly, JS reads it (XSS → theft). Without Secure, it travels in the clear. Without SameSite, it rides cross-site requests (CSRF).

Red Team

Section titled “Red Team”

Discovery

Section titled “Discovery”
  • Inspect the session cookie: length, charset, does it look random or encode something (base64 of a user id)?
  • Compare several tokens issued in a row: if they increment or share a prefix → low entropy, predictable.
  • Check attributes: missing HttpOnly/Secure/SameSite?

By hand

Section titled “By hand”
  • Session fixation: if the server accepts a session ID you fix (via URL or cookie) and does not rotate it after login, you plant your ID in the victim’s browser, they log in, and your ID becomes authenticated.
1. GET https://target/?SESSIONID=attacker_fixed   (or Set-Cookie via XSS/subdomain)
2. the victim authenticates with that same ID
3. the attacker uses SESSIONID=attacker_fixed -> authenticated session
  • No logout invalidation: capture the token, log out, replay a request with the old token. If still valid → logout is cosmetic.
  • No timeout: token valid hours/days after last activity.
  • Concurrent reuse: the same token works from two IPs at once with no alert.
  • Token in URL: shows up in Referer, proxy logs, and history → passive theft.

Prediction

Section titled “Prediction”

If the ID encodes data (base64("user=5:ts=...")) or is sequential, generate other users’ IDs. Measure entropy with Burp Sequencer.

Tools

Section titled “Tools”
  • Burp Suite — Sequencer (entropy), token replay, cookie analysis.
  • cookie-editor / DevTools — attribute tampering.

Impact

Section titled “Impact”

Full impersonation of the victim account without knowing their password; persistence after credential changes if the token is not revoked.

Blue Team

Section titled “Blue Team”

Detection

Section titled “Detection”
  • Same session ID from disparate IPs/geos/user-agents simultaneously.
  • Use of a token after a logout event.
  • Volume of requests with nonexistent/expired tokens (prediction brute force).

Telemetry

Section titled “Telemetry”

Tie each session to its user, origin IP, and issue time; log logouts and invalidations.

Hardening

Section titled “Hardening”
  • Session IDs with ≥128 bits of entropy from a CSPRNG, opaque (no embedded data).
  • Rotate the ID on authentication and on privilege elevation (kills fixation).
  • Invalidate server-side on logout; clearing the client cookie is not enough.
  • Idle and absolute timeout; re-authentication for sensitive actions.
  • Cookie with HttpOnly, Secure, SameSite=Lax/Strict, __Host- prefix, Path=/.
  • Never put the token in the URL; always over TLS.

Response

Section titled “Response”

Invalidate all affected sessions, force a global re-login, rotate the signing secret if sessions are signed (JWT/stateless).

CVEs and real-world cases

Section titled “CVEs and real-world cases”
  • Session fixation — classic class (OWASP); many historical frameworks failed to rotate the ID after login.
  • CVE-2023-34362 (MOVEit) — chained exploitation abusing sessions/tokens after SQLi.
  • Moodle / Jenkins / PHP forums — numerous CVEs for predictable or non-invalidated session tokens.
  • Firesheep (2010) — mass demonstration of session theft from missing TLS on open WiFi.

Testing checklist

Section titled “Testing checklist”
  • Does the session ID have enough entropy? (Burp Sequencer)
  • Is the ID rotated after login? (fixation)
  • Does logout invalidate the token server-side?
  • Are there idle and absolute timeouts?
  • Does the same token work from two origins at once?
  • Does the cookie have HttpOnly, Secure, SameSite?
  • Does the token ever appear in the URL?
  • Does the ID encode manipulable data instead of being opaque?

References

Section titled “References”