Overview
Authentication testing extends to session controls — verifying that the application manages sessions securely after login. This lesson covers testing session management.
Learning objectives
- Identify session controls to test.
- Explain testing session identifiers, flags, and lifecycle.
- Connect session testing to hijacking/fixation risks.
Core concept
Session controls are the mechanisms that keep an authenticated session secure (from the web-security cookies/sessions module). Testing them (within scope) checks: are session identifiers unpredictable and regenerated at login? Are session cookies set with protective flags (HttpOnly, Secure, SameSite)? Do sessions expire (idle/absolute timeouts)? Does logout truly invalidate the session server-side? Weaknesses in any of these enable session hijacking or fixation.
How it works
The tester examines the session lifecycle: inspecting session identifiers for randomness and whether they change on login (fixation check); reviewing session cookie flags; verifying that sessions time out and that logout invalidates the session server-side (replaying an old identifier after logout should fail). This uses test accounts and observation — non-destructive and in-scope. Each control maps to a known weakness: predictable IDs → hijacking; missing regeneration → fixation; missing flags → cookie theft; no expiration/broken logout → lingering sessions. Findings are documented with the corresponding fixes.
Practical example
Testing an authorized application, the tester finds the session cookie lacks the HttpOnly flag and that logging out does not invalidate the session server-side (an old session identifier still works afterward). Both are documented as findings — the missing flag exposes the session to script-based theft, and the broken logout leaves sessions usable — with fixes (set HttpOnly; Secure; SameSite; invalidate sessions server-side on logout). Testing used test accounts and safe observation throughout.
Cybersecurity relevance
Session controls determine whether authenticated state can be stolen or abused, so testing them targets high-impact weaknesses (hijacking, fixation). It directly validates the session-management defenses from the web-security path — identifier strength/regeneration, cookie flags, expiration, and logout invalidation. For defenders, the findings drive concrete session hardening. Session testing complements login testing: securing the login is insufficient if the resulting session is poorly managed. It is a standard part of authorized authentication testing.
Common mistakes
- Testing login but not the session that follows it.
- Not verifying server-side logout invalidation (only checking the cookie is cleared).
- Overlooking session identifier regeneration (fixation) or cookie flags.
Key takeaways
- Session-control testing checks identifier strength/regeneration, cookie flags (HttpOnly/Secure/SameSite), expiration, and server-side logout invalidation.
- Weaknesses map to hijacking (predictable IDs, missing flags) and fixation (no regeneration) and lingering sessions (no expiry/broken logout).
- It validates the web-security session defenses and complements login testing; securing login is insufficient without secure session management.
Check your understanding
- What session controls should authentication testing verify?
- Why is checking server-side logout invalidation (not just cookie clearing) important?