Lab 17: Session Management Attacks

Objective

Exploit three session management vulnerabilities in a live authentication server from Kali Linux:

  1. Token prediction — brute-force a session token generated as MD5(username + unix_timestamp) by leveraging the server's own timestamp endpoint

  2. Session fixation — supply your own session ID and trick the server into associating it with an admin account, then use it for privileged access

  3. Non-invalidated tokens — after a token refresh, confirm the old token remains valid (revocation gap)


Background

Session tokens are the keys to the kingdom after authentication. A weak or predictable token is equivalent to no authentication at all — whoever can guess or fix the token owns the account.

Real-world examples:

  • Drupal (CVE-2014-9016) — session tokens generated with PHP's rand() seeded by microtime(). Because timestamps are predictable, an attacker could enumerate session IDs for any recent login.

  • phpMyAdmin (CVE-2016-6630) — session token generated with insufficient entropy (mt_rand); brute-force possible due to predictable Mersenne Twister seed.

  • Session fixation in banking apps (recurring) — pre-login session ID preserved after login; attacker sets session ID before victim logs in, then uses that ID as authenticated.

  • 2010 Apache Tomcat (CVE-2010-4172) — session fixation via cookie injection; attacker could force a known session ID for any victim, then wait for login.

OWASP coverage: A07:2021 (Identification and Authentication Failures)


Architecture

Time

35 minutes


Lab Instructions

Step 1: Environment Setup


Step 2: Launch Kali Attacker

📸 Verified Output:


Step 3: Predict Alice's Session Token

📸 Verified Output:

💡 MD5 is not a random number generator. MD5(alice + 1772609932) is deterministic — anyone who knows the username and approximate timestamp can reproduce it. Tokens must be generated with a CSPRNG: import secrets; token = secrets.token_urlsafe(32). This generates 256 bits of entropy — computationally infeasible to brute-force regardless of time window.


Step 4: Session Fixation — Inject an Admin Session

📸 Verified Output:


Step 5: Token Non-Invalidation After Refresh

📸 Verified Output:


Step 6: Enumerate All Session Tokens


Step 7: Remediation Demo

Step 8: Cleanup


Remediation Summary

Vulnerability
Root Cause
Fix

Predictable tokens

MD5(user + time) — deterministic

secrets.token_urlsafe(32) — 256-bit CSPRNG

Session fixation

Server accepts client-supplied session ID

Always generate a new session ID server-side on login; ignore any client-supplied value

Token non-invalidation

Old token not deleted on refresh

del SESSIONS[old_token] before storing new one

Further Reading

Last updated