Session Fixation, Hijacking, and Token Replay

A session identifier is the credential a user presents on every request after logging in, so whoever holds a valid session identifier is, to the server, that user. This lesson covers three ways attackers abuse session identifiers: fixation, where the attacker sets the identifier before login; hijacking, where they steal it after login; and replay, where they reuse a captured token. All three end in impersonation.

Analogy🏏Cricket

🍳 Think of it like cooking: A recipe can look flawless on paper, but a head chef only truly judges the dish by tasting the finished plate, because heat, timing, and the actual oven reveal problems the written method never shows. Just as tasting the cooked result catches what reading the recipe cannot, DAST probes the running application and catches the misconfigurations and runtime behaviour that reading the source cannot. This reveals DAST's stance: it judges the dish as it is actually served, not the recipe as it was merely written.

The unifying insight is that the session identifier must be secret, unpredictable, and freshly issued at the right moments. Most defences follow directly from that: regenerate the identifier at login, protect it in transit and from scripts, and give it a limited lifetime. Understanding why each rule exists makes session management far less like a checklist and more like a coherent design.

Analogy🏏Cricket

💰 Think of it like finance: A real audit that actually attempts a sample transaction proves beyond doubt whether a control can be bypassed, with little room for a false alarm, but it can only test the accounts and processes the auditors actually reach. Just as a hands-on audit yields high-confidence, low-false-positive results yet is bounded by what it examines, DAST yields high-confidence findings about real exploitability yet is bounded by the surface it can reach. This reveals its trade-off: what it confirms is solid, but it only confirms what it manages to touch.