Module 9 · Session Tokens — Where Auth Bugs Live After Login

Last updated: April 29, 2026

A session token is a tiny string that represents “I am logged in as user X.” The security of the entire application reduces to: who holds these strings, how they’re generated, and under what conditions they become invalid. Most web breaches boil down to a token handling failure somewhere in that chain.

Why this happens

Session tokens are distributed trust. The server issued the token. For the rest of the session, the server trusts whoever presents it. If the attacker gets the token — by theft, prediction, or logic bug — they become the user. No password needed, no MFA triggered.

Developers focus intense attention on authentication (login flow, MFA, password complexity) and relatively less on session handling. The attacker flips this: they often don’t touch the login flow. They target session tokens that are already issued to legitimate users.

How it goes wrong

1. Token predictability

Old apps used sequential IDs or time-based tokens. Modern apps mostly use cryptographically random tokens. The handful that don’t (often custom schemes in smaller apps) yield to brute force or prediction.

2. Token transmission in URL

Session ID in URL (?PHPSESSID=abc) leaks via referrer, logs, shared bookmarks. Best practice for 20+ years; still appears in legacy apps.

3. Missing HttpOnly / Secure flags

Cookie without HttpOnly: readable by JavaScript → XSS can steal it. Cookie without Secure: sent over HTTP → any on-path attacker captures it. Both are trivial to fix; both are still missing in real apps.

4. SameSite misconfiguration

SameSite=None without proper reason: CSRF surface. SameSite=Lax: a safer default but sometimes breaks legitimate cross-site flows (OAuth), forcing developers to loosen it.

5. Token not rotated on privilege change

User logs in. Token issued. User is promoted to admin. Token remains the same. When token is validated later, additional claims are looked up fresh — but sometimes they’re cached, and cache invalidation is stale.

6. Logout doesn’t invalidate

JWT stateless: “logout” just deletes client-side token. Server still considers it valid until expiration. Real logout requires server-side revocation list (stateful JWT or session store).

7. Token theft without detection

Infostealer on user endpoint exfils cookies. Attacker uses cookie from a different IP / device / country — login works. No anomaly detection; no binding.

8. Refresh token abuse

Short-lived access token + long-lived refresh token is the modern pattern. But refresh tokens often don’t rotate. Leaked RT = persistent access. And when they do rotate, the rotation isn’t family-based, so a leaked RT can be used once before discovery.

9. Concurrent session limits absent

No limit on how many sessions one user has active. Attacker piggy-backs their session alongside the victim’s; no signal.

10. Session fixation

Attacker sets a known session ID (via URL parameter or cookie injection) on a victim’s browser. Victim logs in. Attacker’s known session is now associated with victim’s identity.

Why we look

Because session compromise is account takeover without any login flow attack. In 2023-2024, infostealer malware became the dominant initial-access vector for identity compromise in M365 environments. The attacker doesn’t phish the password or bypass MFA — they steal the session cookie after legitimate login. Modern defensive architectures must assume session theft is possible and contain the blast radius.

For pentesters: session handling is where reports land high severity. For defenders: this is where the Zero Trust principle “never trust, always verify” pays dividends.

What we find

• Cookies missing HttpOnly / Secure / SameSite attributes
• Session IDs in URL query strings (legacy apps)
• JWT with alg=none acceptance, weak HMAC secret, or missing signature validation
• JWT that’s never refreshed — 1-year-long tokens
• Logout endpoint that returns 200 but doesn’t invalidate (cookie / JWT still works after)
• Password change doesn’t invalidate other active sessions
• No IP / device binding or abnormality detection
• Refresh token without rotation or family-based revocation
• Tokens readable from localStorage (XSS extraction)
• OAuth access token stored in cookie without secure flags
• Cross-subdomain cookies broadening the attack surface unnecessarily
• Token endpoint vulnerable to CSRF (attack issues tokens for victim’s session)

Modern defences that matter

1. Strict cookie attributes: HttpOnly + Secure + SameSite=Lax or Strict
2. Short-lived access tokens (15 minutes max) + refresh tokens with rotation + family revocation
3. Token binding: tie token to device fingerprint (user agent, TLS fingerprint, IP range). If the token appears with a different fingerprint: step-up or reject
4. Continuous access evaluation (CAE): cloud IDPs can revoke tokens in seconds on risk events
5. Step-up authentication for sensitive actions even within a session (re-password, re-MFA for high-risk operations)
6. Session inventory visible to users with per-session revocation
7. Logout that actually invalidates the session server-side
8. Idle timeout enforced server-side, not just client
9. Concurrent session limits where appropriate
10. Audit log of session creation, refresh, revocation

Mindset takeaway

Session handling is where the auth story continues after login. Developers who “solved” login often ship fragile session handling because the hard part seemed done. Test session flows end-to-end: issue, use, extend, transfer, invalidate, re-issue. Each state transition is a potential bug. For defenders: assume session theft is possible and build layered mitigations — session handling doesn’t need to be impenetrable, but the cost of compromise should be short-lived.