Weak Session IDs
Weak or predictable session IDs are a critical security vulnerability that allows attackers to hijack user sessions without needing credentials. Session IDs should be cryptographically random and unpredictable - when they’re not, attackers can guess or calculate valid session tokens and impersonate legitimate users.What are Session IDs?
Session IDs are tokens that web applications use to maintain state and identify users across multiple HTTP requests. After successful authentication, the server generates a session ID and sends it to the client, typically as a cookie:Why Session IDs Matter
Session IDs are often the only thing protecting authenticated sessions:- No password needed after login
- Complete account access with valid session ID
- Can perform any action the user can perform
- May persist for hours or days
Attack Scenarios
If an attacker can predict or guess session IDs:- Session Hijacking: Take over active user sessions
- Session Fixation: Force users to use attacker-controlled session IDs
- Privilege Escalation: Hijack admin sessions
- Account Takeover: Full access to user accounts
How the Attack Works
The DVWA Weak Session IDs module demonstrates different session ID generation methods, each with varying degrees of security. The page sets a cookie calleddvwaSession each time a button is clicked:
- Starts at 0 (or wherever the counter is)
- Increments by 1 for each new session
- Completely predictable
1523, other active sessions are likely 1520, 1521, 1522, 1524, 1525, etc.
- Uses
time()function (seconds since Unix epoch) - Current timestamp becomes session ID
- Appears random but is actually predictable
- Predictable based on time
- Low entropy (1 second granularity)
- Easy to brute force small time windows
- Attacker can synchronize with server time
- No cryptographic randomness
High Security
Vulnerability: MD5 hash of sequential number.- Uses
mt_rand()for random number - Combines with
time()for additional entropy - Adds constant string “Impossible”
- Hashes with SHA1
- Sets Secure and HttpOnly flags
- Random component:
mt_rand()adds unpredictability - Time component: Additional entropy
- Salt: “Impossible” string prevents simple reverse lookups
- SHA1 hash: Stronger than MD5 (though SHA256 would be better)
- Secure flag: Cookie only sent over HTTPS
- HttpOnly flag: JavaScript cannot access cookie
- Expiration: Cookie expires after 1 hour
- Path/Domain restriction: Limits cookie scope
2. Session Brute Force
Secure Session Management
1. Generate Cryptographically Secure IDs
3. Session Regeneration
Testing for Weak Session IDs
1. Collection and Analysis
Best Practices Summary
-
Use cryptographically secure random number generators
- PHP:
random_bytes(),random_int() - Python:
secretsmodule - Node.js:
crypto.randomBytes()
- PHP:
-
Ensure sufficient entropy
- Minimum 128 bits (16 bytes)
- Recommended 256 bits (32 bytes)
-
Set proper cookie flags
Secure: HTTPS onlyHttpOnly: No JavaScript accessSameSite: CSRF protection
-
Implement session timeouts
- Idle timeout (15-30 minutes)
- Absolute timeout (2-8 hours)
-
Regenerate session IDs
- On login
- On privilege change
- Periodically during session
-
Validate session integrity
- Check IP address (carefully)
- Verify user agent
- Session fingerprinting
-
Secure session storage
- Database storage (not just files)
- Encrypted session data
- Secure session cleanup
-
Monitor for attacks
- Log session creation/destruction
- Detect unusual patterns
- Alert on suspicious activity
-
Never use:
- Sequential numbers
- Timestamps alone
- Predictable patterns
- Weak hashing of predictable inputs
- MD5 or SHA1 for security purposes
-
Additional protections
- Multi-factor authentication
- Device fingerprinting
- Geolocation checks
- Anomaly detection
