Broken Authentication — Predictable Session Token

Scenario

AcmePortal stores the active session as a base64-encoded string of the form username:timestamp in localStorage (key: acme_session). No HMAC. No server-side validation. Whoever can edit localStorage controls the session.

Steps

1. Click Login in the right pane (any username/password works — auth boundary isn't the lesson here). You'll be logged in as rverma (a regular user).
2. Open browser DevTools → Application → Local Storage → lab.techclick.in. Find the acme_session key.
3. Decode the value (base64). It should look like rverma:1716.... The format is <username>:<unix-timestamp>.
4. Re-encode a new session for the user acme_admin using the same format. (Pick any recent timestamp.)
5. Paste the new base64 string back into the acme_session localStorage value. Reload the page.
6. The page should now show the admin dashboard with the flag.

Why this is broken

• No HMAC/signature → tokens are trivially forgeable.
• Predictable format → no entropy, attackers don't need to break crypto.
• Stored in localStorage → JS-accessible, so any XSS exfiltrates and forges.
• No server-side check on the token's claimed identity.

The flag

TC{broken_auth_…} appears on the admin dashboard after you forge the session.