Session Fixation

Session Fixation and Session Token Exposure

What Is Broken and Why

Session fixation occurs when an application authenticates a user but retains the pre-authentication session token rather than issuing a fresh one. An attacker who plants a known token (via URL parameter, XSS, or network manipulation) can then authenticate as the victim by using that same token once the victim logs in. Session token exposure extends the attack surface by allowing tokens to be harvested from HTTP traffic, proxy logs, browser history, and caches when tokens are transmitted without encryption or appear in GET request URLs. Predictable session tokens that can be forged complete the trifecta of session management failures.

Key Signals

• Application does not set a new Set-Cookie header upon successful authentication
• Pre-login session token remains usable in authenticated requests post-login
• Session ID appears in URL query string: ?JSESSIONID=... or ?session=...
• Session ID transmitted over HTTP (not HTTPS) at any point
• Set-Cookie lacks Secure flag on session cookies
• Set-Cookie lacks HttpOnly flag on session cookies
• Session cookies set without SameSite attribute
• Session ID predictable: sequential, timestamp-based, or short (< 50 chars / < 128-bit entropy)
• Cache-Control headers on authenticated pages do not include no-store
• ASP.NET Forms Authentication cookies (.ASPXAUTH) used without server-side session store
• Set-Cookie: __Host- or __Secure- prefixes absent (weaker binding guarantees)

Methodology

1. Pre-auth token capture: Visit the login page without authenticating; record all cookies issued (note Set-Cookie headers, cookie names, values).
2. Authentication with token intact: Submit valid credentials while preserving the pre-login cookie; inspect response for Set-Cookie headers.
3. Fixation test: If no new session cookie issued, the pre-auth token has been elevated to an authenticated session — fixation confirmed.
4. Forced cookie test: Using two accounts (attacker + victim), perform the 9-step forced cookie scenario: snapshot pre-login cookies, authenticate as victim, restore pre-login snapshot, attempt authenticated action, then swap and authenticate as attacker using victim's pre-login cookies.
5. Token randomness analysis: Collect 50+ session tokens under identical conditions within a 50ms window; load into Burp Sequencer for statistical analysis.
6. Transport exposure: Force HTTP access after authentication; observe if session cookie is transmitted. Check for Secure flag.
7. GET parameter exposure: Review all URLs and server logs for session IDs in query strings.
8. Cache exposure: Check Cache-Control, Pragma, and Expires headers on authenticated responses.

Payloads & Tools

# Step 1: Capture pre-login token
PRE_TOKEN=$(curl -s -c /tmp/pre_cookies.txt "https://TARGET/login" \
  -D - | grep -i "set-cookie" | grep -i "session\|jsession\|sid")
echo "Pre-login token: $PRE_TOKEN"

# Step 2: Authenticate while keeping pre-login token
curl -s -b /tmp/pre_cookies.txt -c /tmp/post_cookies.txt \
  -X POST "https://TARGET/login" \
  -d "username=VICTIM&password=VICTIM_PASS" \
  -D - | grep -i "set-cookie"

# Step 3: Compare pre and post tokens
echo "=== Pre-login cookies ===" && cat /tmp/pre_cookies.txt
echo "=== Post-login cookies ===" && cat /tmp/post_cookies.txt

# Step 4: Test if pre-login token grants authenticated access
curl -s -b "JSESSIONID=PRE_LOGIN_TOKEN_VALUE" \
  "https://TARGET/account/dashboard" -o /dev/null -w "%{http_code}"

# Transport exposure test
curl -v "http://TARGET/account/profile" \
  -b "SessionID=VALID_TOKEN" 2>&1 | grep -iE "set-cookie|location|HTTP/"

# GET parameter session ID test
curl -s "https://TARGET/page;jsessionid=SESSION_ID_VALUE" \
  -D - | grep -i "set-cookie\|200\|302"

# Cache header audit on authenticated page
curl -sI "https://TARGET/account/dashboard" \
  -b "SessionID=VALID_TOKEN" | grep -iE "cache-control|pragma|expires"

# Token entropy collection for Burp Sequencer
# (In Burp: Proxy > HTTP History > select login response > right-click > Send to Sequencer)
# Collect 100+ tokens, run analysis for effective bits of randomness

# ASP.NET Forms Auth cookie decode (check if user ID is embedded)
python3 -c "
import base64, sys
token = 'TOKEN_VALUE_HERE'
try:
    decoded = base64.b64decode(token + '==')
    print(decoded)
except Exception as e:
    print(f'Error: {e}')
"

Bypass Techniques

• If __Host- or __Secure- prefixed cookies are absent, attacker can potentially set cookies via HTTP subdomain or path injection to fix the session.
• Some frameworks issue a new session ID but keep the old one valid ("soft rotation"); the old token remains usable, effectively still allowing fixation.
• ASP.NET Forms Authentication without server-side session state allows restoring old auth cookies after logout if the machine key is static and the cookie has not expired.
• Session tokens in URL fragments (#) are not sent to servers but may leak via Referer headers.

Exploitation Scenarios

Scenario 1 — Classic Session Fixation Setup: Application issues session token on first visit; does not rotate after login. Trigger: Attacker tricks victim into visiting https://TARGET/login?sessionid=KNOWN_VALUE (if app accepts session via URL); victim logs in; attacker uses same KNOWN_VALUE to access victim's authenticated session. Impact: Full account takeover without knowing victim's credentials.

Scenario 2 — Network Attacker Cookie Forcing Setup: Application accepts cookies over HTTP for legacy endpoints; no __Host- prefix protections. Trigger: Attacker on same network injects a known session cookie via HTTP response manipulation; victim authenticates; attacker uses planted cookie to access authenticated session. Impact: Session hijacking of any user on the same network segment.

Scenario 3 — ASP.NET Cookie Restoration After Logout Setup: Application uses encrypted Forms Authentication cookie without server-side session store; machine key is static. Trigger: Post-logout, attacker restores captured .ASPXAUTH cookie (still cryptographically valid, only blacklisted client-side); sends it to authenticated-only endpoint. Impact: Session restoration after logout; authentication state bypass.

False Positives

• A new Set-Cookie with the same value as the pre-login token may be a refresh/expiry update, not a true rotation; only a different value confirms proper rotation.
• Cache-Control: private appears protective but still allows browser-local caching; only no-store prevents all local caching.
• Session IDs that look short in display may be Base64-encoded 256-bit values; decode before judging entropy.

Fix Patterns

• Invalidate the existing session and issue a new session ID immediately upon successful authentication (session_regenerate_id(true) in PHP; Session.Abandon() + new session in ASP.NET).
• Set Secure, HttpOnly, and SameSite=Strict (or Lax) on all session cookies.
• Use __Host- prefix for session cookies to enforce secure origin, host-only scope, and Path=/.
• Never transmit session IDs in URLs or GET parameters.
• Enforce Cache-Control: no-cache, no-store and Pragma: no-cache on all authenticated responses.
• Use server-side session stores; do not rely solely on client-side encrypted tokens for auth state.
• Generate session IDs with 256-bit entropy (AES-based); enforce minimum 50-character length.

Related Skills

Session fixation and [[cookie-attacks]] are two sides of the same session management problem — fixation exploits the lack of rotation on login, while cookie-attacks exploit weak attributes after the session is established. [[csrf]] can be used to fix a session: if a login form accepts a GET with a sessionid parameter, a CSRF payload can force the victim's browser to submit it. Missing __Host- or __Secure- prefixes (covered in [[cookie-attacks]]) are also prerequisites for session fixation via HTTP subdomain injection.