Web Session

One-liner: A mechanism to maintain user state across multiple HTTP requests by associating a unique identifier with server-side data.

🎯 What Is It?

Since HTTP Requests are stateless (each request is independent), web sessions provide a way to "remember" users across requests. After Authentication, the server creates a session and gives the client a session identifier (usually in a Cookie). This ID is sent with every request, allowing the server to look up the user's session data.

🤔 Why It Matters

• Sessions are the backbone of authenticated web applications
• Session vulnerabilities lead to account takeover
• Understanding sessions is critical for web security testing
• Common target for attackers (session hijacking, fixation)

🔬 How It Works

Session Flow

1. User submits credentials
2. Server verifies identity
3. Server creates session (stores user data server-side)
4. Server sends session ID to client (Set-Cookie: PHPSESSID=abc123)
5. Client includes session ID in subsequent requests
6. Server looks up session data using ID
7. User logs out → Session destroyed

Diagram

┌─────────┐                        ┌─────────┐
│ Browser │                        │ Server  │
└────┬────┘                        └────┬────┘
     │ POST /login (user:pass)          │
     │─────────────────────────────────>│
     │                                  │ Create session
     │    Set-Cookie: session=xyz       │ Store user data
     │<─────────────────────────────────│
     │                                  │
     │ GET /dashboard                   │
     │ Cookie: session=xyz              │
     │─────────────────────────────────>│
     │                                  │ Lookup session
     │    200 OK (user's data)          │ Return user data
     │<─────────────────────────────────│

📊 Session Storage Types

🚨 Session Vulnerabilities

🛡️ Detection & Prevention

How to Detect (Blue Team)

• Monitor for session IDs used from multiple IPs
• Detect impossible travel (same session, distant locations)
• Track session creation/destruction patterns
• Alert on session reuse after logout

How to Prevent / Mitigate

• Regenerate session ID after authentication
• Use cryptographically secure random session IDs
• Implement both idle and absolute session timeouts
• Properly invalidate sessions on logout (server-side)
• Bind sessions to client fingerprint cautiously

🔧 Session Testing with cURL

Capture session after login:

curl -c session.txt -d "username=admin&password=admin" http://target.com/login

Reuse session for authenticated request:

curl -b session.txt http://target.com/profile

Test session after logout:

# After logging out, try reusing the old session
curl -b session.txt http://target.com/profile
# Should be redirected or get 401

🎤 Interview Angles

Common Questions

• "How do web sessions work?"
• "What's the difference between session-based and token-based auth?"
• "Explain session hijacking and how to prevent it"
• "How would you test session management security?"

STAR Story

Situation: During a security assessment, discovered the application didn't regenerate session IDs after login.
Task: Demonstrate the session fixation vulnerability and recommend remediation.
Action: Showed how an attacker could set a victim's session ID before login, then hijack the authenticated session afterward. Recommended regenerating session ID post-authentication.
Result: Development team implemented session regeneration, eliminating the fixation vulnerability.

✅ Best Practices

• Always regenerate session ID after authentication state change
• Use 128+ bit random session IDs
• Set appropriate session timeouts (idle: 15-30 min, absolute: 8-24 hrs)
• Invalidate session server-side on logout
• Use secure Cookie flags (HttpOnly, Secure, SameSite)

🔗 Related Concepts

• Cookie
• HTTP Request
• Authentication
• Session Hijacking
• cURL
• Cross-Site Scripting (XSS)

📚 References

• OWASP Session Management Cheat Sheet
• OWASP Testing Guide - Session Management