Session fixation
In web application security, session fixation is an attack in which the attacker sets or learns a session identifier before the victim authenticates, and the application keeps that same identifier after login. The attacker then presents the identifier and is inside the authenticated session without ever knowing the password.
The precondition is an application that accepts a session identifier it did not issue, or that issues one to an anonymous visitor and then reuses it once that visitor logs in. Delivery is whatever the application allows: a link carrying the identifier in the query string, a subdomain that can write the parent domain’s cookie, or a response header the attacker can influence. Nothing is stolen in transit, which is what separates fixation from session hijacking.
The fix is one line of behaviour: issue a new identifier at every change of privilege, and invalidate the old one server side rather than only clearing the cookie. Accepting identifiers from the URL should be off entirely.
In practice this reaches a report less often than it used to, because most frameworks now rotate on login by default. Where we still find it is in custom authentication code, in single sign on integrations that carry a session across two domains, and in applications that rotate the cookie but keep the old server side session alive. The evidence is the same identifier before and after authentication, captured in the proxy log, which is what we hand over as part of how we test authentication and session handling.