41. Session Hijacking – Tokens, Cookies and Defence
41.6 Application-Level Hijack – URL Tokens, CSRF, JWT Concepts
Not every hijack is Wi-Fi sniff:
- Session ID in URL (
?PHPSESSID=...) – leaks via Referer, logs, screenshots, shoulder surfing - CSRF vs session: CSRF = browser already has victim cookie; attacker tricks browser to send request. Different from stealing cookie – but related session hygiene (SameSite, CSRF tokens)
- JWT pitfalls (concept level): token in localStorage → XSS readable; none / weak
alg; long expiry; no revoke list; secrets in client
Blue habits:
- Prefer cookie session with HttpOnly over URL SID
- CSRF token on state-changing POSTs; SameSite=Lax/Strict
- JWT: short TTL, secure storage choices, validate
alg/iss/aud, rotate secrets server-side
| Red team (attacker) does | Blue team (defender) detects / stops |
|---|---|
| Copies SID from URL bar / proxy log | Cookie-based SID; regenerate; no SID in GET |
| CSRF on "transfer / change email" while session valid | CSRF token + SameSite; re-auth for sensitive ops |
| Abuses fat JWT in localStorage via XSS | Prefer HttpOnly cookie patterns where fit; CSP; short JWT TTL |
Ravindra Bagale's Tip
Students JWT = "modern = automatically safe". JWT = format; safety = how you sign, store, expire, validate. Interview madhe pitfalls 3 bola. He lakshat theva.
Practice task
Raja-Rani Traders wants "remember me for 30 days" JWT in localStorage. Write 10-line risk memo for owner Raja: XSS, theft, revoke difficulty. Propose safer pattern (short access + refresh, HttpOnly cookie, or server session). No production deploy without HTTPS.