← Recipes

阅读中文版本

Prevent Session Fixation on Login

Rotate the session identifier on privilege change, regenerate the cookie after authentication, and invalidate the pre-login session so a fixed id cannot be reused.

~30 minauthenticationsessionsecurity

Task

Regenerate session ids on login so an attacker who set a session id cannot hijack the authenticated session.

When to use this

An attacker plants a known session id, the victim logs in with it, and the attacker now shares the victim authenticated session.

Prerequisites

  • A session middleware with id regeneration
  • HTTPS and secure cookie settings

Steps

1. Regenerate the session id immediately after successful authentication.

Expected output: The authenticated session uses a new id.

2. Invalidate the pre-login session data and cookie.

Expected output: The attacker-held id no longer maps to a valid session.

3. Also rotate on privilege elevation and on logout.

Expected output: Sensitive transitions always get fresh ids.

4. Set cookie flags: HttpOnly, Secure, and a sensible SameSite.

curl -i https://app.example.com/login -c cookies.txt

Expected output: The cookie cannot be read by script or sent cross-site.

Troubleshooting

Problem

Old session still valid

Solution

Destroy the old server-side session, not only set a new cookie.

Problem

Concurrent tabs break

Solution

Regeneration is expected to invalidate other tabs; document it or use a shared session store carefully.

Limitations

  • Regeneration can log out other tabs of the same user unless sessions are shared deliberately.
  • It does not mitigate token theft after login; that needs TLS and short-lived credentials.

Context

Regenerate session ids on login so an attacker who set a session id cannot hijack the authenticated session. An attacker plants a known session id, the victim logs in with it, and the attacker now shares the victim authenticated session.

Steps

  1. Regenerate the session id immediately after successful authentication. Expected: The authenticated session uses a new id.
  2. Invalidate the pre-login session data and cookie. Expected: The attacker-held id no longer maps to a valid session.
  3. Also rotate on privilege elevation and on logout. Expected: Sensitive transitions always get fresh ids.
  4. Set cookie flags: HttpOnly, Secure, and a sensible SameSite. Expected: The cookie cannot be read by script or sent cross-site.
app.post('/login', (req, res) => {
  // verify credentials first
  req.session.regenerate((err) => {
    if (err) return res.status(500).end();
    req.session.userId = user.id;
    res.json({ ok: true });
  });
});

Verify

  • The authenticated session uses a new id.
  • The attacker-held id no longer maps to a valid session.
  • Sensitive transitions always get fresh ids.
  • The cookie cannot be read by script or sent cross-site.

Limits

  • Regeneration can log out other tabs of the same user unless sessions are shared deliberately.
  • It does not mitigate token theft after login; that needs TLS and short-lived credentials.