Ravindra BagaleCourses & study guides

41. Session Hijacking – Tokens, Cookies and Defence

41.3 Session Fixation and Predictable IDs

By Last updated:

Session fixation: attacker sets (or knows) a session ID before victim logs in; victim authenticates into that same ID; attacker reuses it. Classic weak pattern: accept attacker-supplied session ID and never regenerate after successful login.

Predictable IDs: if session IDs are short, sequential, or weak RNG, Red can guess. Modern frameworks use long random IDs – still regenerate on privilege change.

Blue classics:

  • session_regenerate_id(true) (PHP) after successful login
  • Reject / ignore attacker-chosen IDs where framework allows
  • Never put session ID in bookmarks / email links if avoidable
Red team (attacker) does Blue team (defender) detects / stops
Plants known session ID; waits for victim login Regenerate session ID on login; invalidate old
Guesses weak / sequential IDs Cryptographically strong long IDs from framework
Shares "helpful" login URL with embedded SID Avoid SID in URL; Prefer cookies + regenerate

Ravindra Bagale's Tip

Students keep the same PHPSESSID even after a successful login. Close the fixation door: regenerate on login. One line for the interview: "I rotate the session identifier at authentication." Don't worry – one function call, a big difference.

Lab

Deliberate weak PHP on OWN VM: login without regenerate. From Kali, note SID before login (or set cookie), complete login as Rani in browser, replay SID from Kali curl – see authenticated page. Then add session_regenerate_id(true) after password OK. Prove old SID fails. Host-only only.