Session Fixation

Session fixation is an attack where the attacker doesn't steal your session, they get you to log into theirs. The mechanism: many web apps issue a session identifier (often a cookie) before you've even logged in, and some of them make the mistake of keeping that same identifier valid after you log in, rather than issuing a brand-new one. If an attacker can get a victim to visit the site carrying an identifier the attacker already knows, via a crafted link, a shared network, or a cross-site request, and the victim then logs in, the attacker's pre-chosen identifier becomes a valid, authenticated session. The attacker never captured anything from the victim; they picked the lock before the victim ever touched the door.

The standard fix is simple to state and easy to get subtly wrong in implementation: always issue a fresh session identifier the moment authentication succeeds, and invalidate whatever identifier existed before. A related variant that shows up specifically in OAuth/OIDC login flows, sometimes called "login CSRF", is an attacker tricking a victim's browser into completing an authorization-code exchange the attacker initiated, so the attacker's third-party account gets linked to the victim's session. The fix there is the same idea applied to the redirect step: bind the authorization request to the specific browser that started it (typically via a state-carrying cookie set at the start of the flow and checked again at the callback), so a code or state value harvested elsewhere can't be replayed into someone else's browser.

Where it comes from

The attack was first formally written up by Mitja Kolšek of Acros Security in a 2002 paper. OWASP has since made testing for it (test case WSTG-SESS-03 in the OWASP Web Security Testing Guide) and defending against it (the OWASP Session Management Cheat Sheet) part of its standard public guidance. Nobody owns this the way a standards body owns a protocol spec, it's accumulated security-community knowledge, and Solidus contributed none of it.

Solidus today

Verify's enterprise SSO module binds every SSO login attempt to the browser that started it: a signed binding cookie is set at /start and checked, before the authorization code is ever exchanged, at the callback, so a (code, state) pair captured by an attacker and pasted into a victim's browser fails with a 401 rather than minting a session. That specific defense is real, tested code, but it's part of an enterprise-account-gated feature, not something a stranger can freely exercise today. More generally, Solidus's own login (via did:solidus challenge/response, or via OIDC at auth.solidus.network) only ever issues a session token after authentication succeeds, rather than reusing a pre-authentication identifier, the baseline mitigation this entire entry describes.

See also

OIDC and OAuth 2.0 are the protocols where the login-CSRF variant of this attack shows up. PKCE closes a related but distinct authorization-code-interception gap. Presentation Attack is this Lexicon's other named attack-class entry, for biometric liveness rather than sessions.