Session Fixation

What is Session Fixation

In normal session hijacking, the attacker steals an existing session. In session fixation, the attacker sets the session ID before the victim authenticates — then after the victim logs in, the attacker uses the same known session ID to access the authenticated session.

Three conditions needed:

1. The app accepts session IDs provided by the user (via URL, cookie injection, or form).
2. The session ID does not change on login (no session regeneration).
3. The same session ID grants authenticated access after login.

---

Detection

Step 1 — Check if session ID is accepted from URL

Visit the app and inject a known session ID via query parameter:

https://TARGET/login?PHPSESSID=ATTACKER_CONTROLLED_VALUE
https://TARGET/login?sessionid=fixedvalue123
https://TARGET/login?sid=fixedvalue123

In Burp Proxy, check the Set-Cookie response header after visiting these URLs. If the app sets a cookie matching the value you provided (or uses the URL parameter as the session) → session adoption confirmed.

Step 2 — Check for session regeneration on login

1. Note your session ID before login (from cookie).
2. Log in.
3. Check the session ID after login.

In Burp Proxy → HTTP history, find the login request and the response. Compare Set-Cookie in the response with the session cookie from the login request.

If session ID is the same before and after login → vulnerable.

Step 3 — Test cookie injection

If the app has a header injection or CRLF vulnerability, plant a session cookie:

https://TARGET/page?redirect=https://TARGET%0d%0aSet-Cookie:+PHPSESSID=fixedvalue123

---

Exploitation

Full session fixation attack flow

1. Attacker visits the site → receives a session ID (e.g. PHPSESSID=abc123).

2. Attacker sends the victim a link with the known session ID in the URL:

   https://TARGET/login?PHPSESSID=abc123

   Or plants the session via a subdomain CRLF injection, XSS, or social engineering.

3. Victim clicks the link and logs in using the attacker’s session ID.

4. App does NOT regenerate the session on login — abc123 is now an authenticated session.

5. Attacker uses abc123 as their cookie → they are logged in as the victim:

   curl -b "PHPSESSID=abc123" https://TARGET/account

Burp replay

1. Intercept a request and note the session cookie.
2. Open a second Repeater tab representing the “attacker” browser.
3. Send an authenticated request with the fixed session cookie.
4. If it returns authenticated content → confirmed.

---

Session Fixation via Subdomain Cookie

If the app sets cookies on .target.com (dot-prefix) and an attacker controls a subdomain:

// On attacker.target.com
document.cookie = "PHPSESSID=fixedvalue; domain=.target.com; path=/";

Then redirect the victim to target.com/login. The victim’s browser sends PHPSESSID=fixedvalue — planted by the attacker’s subdomain.

---

Post-Login Fixation

Even if the app regenerates the session on login, check if it does so on privilege change:

• Switching from a free to a paid account
• Admin elevation
• Password change
• Email change

If the session ID doesn’t change when privilege changes → post-login fixation is possible.

---

Combined with Session Riding

After fixing the session and waiting for the victim to authenticate, the session can be used for CSRF-like actions — but since you control the full session, no CSRF token is needed:

curl -b "PHPSESSID=abc123" -X POST https://TARGET/settings \
  -d "email=attacker@evil.com"

---

Burp Suite workflow

1. Proxy — intercept the login flow; compare session ID in pre-login request vs post-login Set-Cookie header.
2. Repeater — manually inject a known session ID via URL parameter (?PHPSESSID=test); check if the response sets a cookie with that value.
3. Two Repeater tabs — one as “victim” (logs in with fixed session), one as “attacker” (sends requests with the same fixed session) — confirm the attacker tab gains access after the victim logs in.
4. Scanner — active scan checks for session regeneration on login.