Authentication and Access Control


Web Security.

Every request a web application handles raises two questions: who is this, and are they allowed to do what they're asking? Get the first wrong and anyone can claim to be anyone. Get the second wrong and a logged-in user reaches data that was never theirs.

Both answers ride on information the client controls. The browser hands over a username, a cookie, an ID in a URL, and the server decides how much of it to believe. This module is about what happens when it believes too much.



Authentication Bypass

Once you log in, a web app has to recognize you on every request that follows. The usual way is a session: the server hands your browser a random identifier and keeps its own record of which account that identifier belongs to. The value means nothing by itself, and only the server knows what it stands for.

Mail skips all of that. When you log in, it puts your username directly in the URL and serves your mailbox from a path like /u/hacker/. From then on, every request names the account it wants right in the path, and the app believes it. But the address bar is yours to edit, and nothing checks that the name in the path is the one you logged in as.

Your account is hacker:1337. The flag is in the admin mailbox. Read /challenge/server if you want to see exactly how the mailbox route decides whose mail to show.

Same idea as the last challenge, moved out of the address bar. This time Mail sets your username as a cookie when you log in, a session cookie holding the name itself, and reads it back on every request. Naming a cookie session doesn't make it one. A real session cookie holds a random token, or signed data the server can verify. This one holds your username in plain text, and the browser sends whatever you put in it.


30-Day Scoreboard:

This scoreboard reflects solves for challenges in this module after the module launched in this dojo.

7-Day | 30-Day | All-Time

Hackers Crews
Rank Hacker Badges Score