Session Fixation in a Legacy Authentication Flow
A B2B SaaS platform lets tenants configure SSO. During a review you notice the login flow: GET /login issues a pre-authentication session cookie (JSESSIONID) and a hidden CSRF token; POST /login validates credentials, then calls HttpSession.invalidate() and creates a new session, but reuses the same JSESSIONID value by copying it from the old session into the new one via a custom session-id generator. The app also accepts a session id passed as a URL query parameter (?jsessionid=...) for 'legacy integration support,' and the load balancer does not strip query strings before logging them to a third-party APM that 40 engineers can access. A penetration tester reports she can authenticate as another user by sending a crafted link. The vendor says 'session rotation is implemented, so this is a false positive.'
1. Evaluate the vendor's claim that session rotation is implemented. What is the actual defect, and how would you demonstrate it?
Read the worked answer
Rotation means the identifier changes on privilege change, not just that a new session object exists. Here invalidate() plus a new session that reuses the same ID is not rotation - the attacker-chosen ID survives authentication. Because the app also accepts ?jsessionid= in the URL, an attacker can: (1) obtain any session id, (2) send a victim a link https://app/login?jsessionid=ATTACKER_ID, (3) victim logs in, (4) attacker replays ATTACKER_ID and is now authenticated as the victim. Demonstration: capture the pre-auth cookie, complete login in a clean browser while forcing that cookie value, then show the post-auth request succeeds with the original ID. The vendor claim is wrong on the mechanism; the acceptance of client-supplied IDs is the root cause.
2. The APM logs full URLs. What is the security consequence and what is your remediation priority ordering?
Read the worked answer
Query-string session IDs are written to APM logs readable by 40 engineers and likely retained for months - that is a standing credential-leak channel (session hijacking via log access, plus insider risk). Priority: (1) stop accepting session IDs from URLs entirely (this is the root cause of both fixation and leakage); (2) enforce server-generated, rotated IDs on authentication - regenerate a fresh random ID, do not copy; (3) purge/redact historical logs containing jsessionid; (4) restrict APM access and add query-string scrubbing at the LB. Fixing only the logs leaves fixation open; fixing only rotation leaves the leak. Treat the URL-acceptance as the single highest-leverage fix.