Session Forgery
The Signal That Lied
Echo hears two kinds of signals: the warm pulse of a token that checks out, and the cold loop of something forged. This Vault listens to the signal's own claim about how it was signed — Echo would catch that. The Vault didn't get the memo.
Log in with any username to receive a signed session token. The Vault only opens for admin. The server never tells you the signing secret — but it does trust whatever the token says about itself.
Find the flag, in the format SPAM{this_is_an_example}. This container resets every 24 hours.
What's the vulnerability?
- Signed tokens include a header declaring which algorithm was used — e.g.
{"alg":"HS256"}. - A naive verifier reads that claim from the token and acts on it, including
"alg": "none"— which means "don't verify a signature at all." - If the server honors that claim, anyone can craft a token, declare it unsigned, and have the server trust its payload.
Why does it matter?
The entire point of signing a token is that the server — not the client — decides what's trustworthy.
If verification takes its instructions from the token itself, the attacker chooses whether their forged session
gets checked. From there, setting role: admin is trivial.
How to fix it
Pin the expected algorithm server-side. Never let the token dictate its own verification.
Use a well-reviewed JWT library configured with an explicit algorithms allow-list
— ["HS256"] — and reject anything that doesn't match before touching the payload.