logon picoCTF 2019 Solution

Description

1. Step 1

   Log in with any credentials

   Observation

   I noticed the challenge description says 'Log in and access the flag' without giving any credentials, which suggested the server grants a session to any user and the real vulnerability lies in what happens after authentication.

   The login form accepts any username and password - submit whatever you like. After logging in, the page will say you are not an admin.

   What didn't work first

   Tried: Trying common default credentials like admin/admin or admin/password expecting a hidden admin account.

   The login form really does accept anything, so credential guessing is unnecessary. The server grants a session to any user regardless of what you type. The real challenge starts after you are already logged in.

   Tried: Looking at the page source for a hidden form field or URL parameter that controls admin access.

   The authorization flag is not in the HTML - it is in a cookie set by the server after login. View Source will not show cookie values. You need to open DevTools and check the Application or Storage panel to see what cookies the server set.

   Learn more

   Many web challenge servers accept any credentials to give players an authenticated session, then restrict access based on a separate authorization check. The distinction between authentication (proving who you are) and authorization (what you are allowed to do) is fundamental in security. This challenge demonstrates a common authorization failure: the server correctly authenticates users but then relies on a client-controlled value (a cookie) to determine privilege level.

   When you log in, the server sets a session cookie in your browser. Cookies are name-value pairs stored by the browser and sent automatically with every request to the same domain. They are the standard mechanism for maintaining state in HTTP, which is inherently stateless. The server uses the cookie to recognize returning users without requiring a password on every request.

   The critical mistake here is trusting a cookie value that the user can freely modify. Cookies are stored on the client and are fully readable and writable by the user - they provide zero security guarantees unless they are cryptographically signed or the values are verified server-side.

2. Step 2

   Modify the admin cookie

   Observation

   I noticed that after login the page says I am not an admin, which suggested the server is reading a client-controlled value (a cookie) to determine privilege rather than enforcing access server-side.

   Open browser Developer Tools (F12), go to Application > Cookies, and find the cookie named 'admin'. Its value is currently 'False'. Double-click the value and change it to 'True'. Refresh the page.

   What didn't work first

   Tried: Going to the Console tab and typing document.cookie to read cookies, then not realizing you can also set them the same way.

   document.cookie does let you read and write cookies, but the output format is a single semicolon-separated string that can be confusing. The Application tab in Chrome or Storage tab in Firefox shows each cookie as a clearly labeled row with an editable value field - much easier for finding and changing the 'admin' cookie directly.

   Tried: Editing the cookie value and clicking around the page without refreshing, then seeing no change and thinking the edit did not work.

   Browsers send cookies with each new HTTP request. Simply changing the cookie value in DevTools does not re-send it to the server - you must refresh the page (F5 or Ctrl+R) so the browser makes a new request to the server carrying the updated cookie value.

   Learn more

   Browser Developer Tools (opened with F12 or Ctrl+Shift+I) expose everything the browser knows about a page. The Application tab (Chrome/Edge) or Storage tab (Firefox) shows all cookies, localStorage, sessionStorage, and IndexedDB entries for the current site. Cookies can be viewed, edited, added, and deleted directly in this interface.

   Alternatively, cookies can be manipulated via the JavaScript console: document.cookie = 'admin=True' sets the admin cookie. Command-line tools like curl let you send arbitrary cookies in requests: curl -b "admin=True" http://challenge-url/. Browser extensions like EditThisCookie provide a more convenient interface for cookie manipulation during testing.

   From a real-world security perspective, this vulnerability is a textbook example of broken access control (OWASP Top 10 A01). The fix is to never store authorization state in client-controlled cookies. Instead, store a session identifier in the cookie that maps to server-side session data (a database record or in-memory store) that the client cannot tamper with. Frameworks like Flask (server-side sessions), Django (signed session cookies with SECRET_KEY), and Express (express-session) handle this correctly by default.

3. Step 3

   Collect the flag

   Observation

   I noticed the server accepted the modified 'admin=True' cookie without any server-side verification, which suggested that simply refreshing after the edit would cause the server to trust the tampered value and reveal the flag.

   With the admin cookie set to True, the server trusts you are an admin and displays the flag.

   Learn more

   The server reads the admin cookie value directly and uses it as the authorization decision without any verification. This pattern - trusting client-supplied data for security decisions - is one of the most common web security mistakes. The server-side code likely looks something like: if request.cookies.get('admin') == 'True': show_flag().

   Secure alternatives the developer should have used:

   • Server-side sessions: Store a random session token in the cookie; keep the admin flag in the server's session store (database, Redis, etc.)
   • Signed cookies: Cryptographically sign the cookie contents so tampering is detectable (Flask's session object does this)
   • JWT with signature verification: Use signed JSON Web Tokens where the signature is verified server-side before trusting claims

   Cookie manipulation challenges like this one are a gateway into more advanced web vulnerabilities: JWT algorithm confusion attacks, session fixation, and cookie injection all involve similar concepts of understanding and manipulating client-side state to subvert server-side authorization.

Flag

Client-side authentication via cookies is trivially bypassable - any user can modify their own cookies using browser developer tools.