Session fixation prevention on login

Context

Authentication review of a PHP application that managed sessions manually rather than through a framework guard.

Scope

Login, logout, privilege elevation and session cookie configuration.

Vulnerability

The session identifier issued before login remained unchanged after successful authentication, and the application accepted a session identifier supplied in the URL by a legacy compatibility setting.

Root cause

session_regenerate_id() was never called on privilege change, and session.use_trans_sid had been left enabled to support a long-retired client.

Impact

An attacker who could set or observe a victim's pre-authentication session identifier could use that identifier after the victim logged in, obtaining an authenticated session without credentials.

Remediation

• Regenerated the session identifier on login, on logout and on any privilege change, deleting the old session data.
• Disabled session.use_trans_sid and session.use_only_cookies=0, so identifiers travel only in cookies.
• Set HttpOnly, Secure and SameSite=Lax on the session cookie, with an absolute and idle timeout.
• Bound sessions to a coarse client fingerprint and invalidated all other sessions on password change.

Retesting

Retesting pre-set an identifier, completed a legitimate login in a second browser and confirmed the original identifier was rejected. URL-borne identifiers were ignored. Session expiry and logout invalidation behaved as configured.

Lessons

• Any change of privilege deserves a new session identifier, not only login.
• Compatibility settings outlive the clients that needed them; audit the runtime configuration, not just the code.