Power Cookie

Description

Solution

1. Step 1Inspect the JavaScript
   The main page shows the onclick handler that creates `isAdmin=0`, so you know which cookie name to modify.
   Learn more

   HTTP cookies are small key-value strings that browsers store and automatically send with every request to the matching domain. Servers use them for session management, user preferences, and authentication state. Because cookies live in the browser, users have full read and write access to them via DevTools or JavaScript.

   In this challenge, the developer made a classic mistake: trusting a client-controlled value (isAdmin=0) for an authorization decision. The server should never rely on data from the client alone to determine privilege levels. Any value the client sends can be forged.

   To inspect cookies in Chrome or Firefox, open DevTools (F12), go to the Application tab (Chrome) or Storage tab (Firefox), and expand the Cookies section. You can double-click any value to edit it directly.

   Cookies can also be manipulated via JavaScript in the browser console. Running document.cookie = "isAdmin=1" creates or overwrites the cookie immediately without needing the Application tab. This technique is useful when the DevTools storage panel is cumbersome or when you need to set multiple cookies quickly during a competition. However, cookies marked with the HttpOnly flag cannot be accessed this way - they are invisible to JavaScript and must be edited through the DevTools storage panel directly.

   For command-line-based testing, curl allows you to specify custom cookies with -b "isAdmin=1" and inspect the full HTTP response without a browser. This is faster for scripted testing and lets you see raw response headers that browsers sometimes obscure. The combination of browser DevTools for initial exploration and curl for precise, repeatable requests is a standard web testing workflow.

2. Step 2Toggle the cookie
   Edit the cookie value (or create a new `isAdmin=1` cookie) and revisit `/check.php` to read the flag.
   Learn more

   Cookie tampering is one of the simplest web attack techniques. Because browsers freely expose cookie storage to the user, any client-side authorization check is trivially bypassed. Proper implementations use signed sessions - the server cryptographically signs the session data so any modification is detected.

   Secure cookie practices include: setting the HttpOnly flag to prevent JavaScript access, the Secure flag to enforce HTTPS-only transmission, and SameSite=Strict to prevent cross-site request forgery. However, none of these prevent a user from modifying their own cookie value in DevTools.

   The real fix is server-side session validation: store the admin flag in a server-side session keyed by a random, unpredictable session token. The token itself is useless without the server's session data, so tampering with the cookie value achieves nothing.

   Many modern frameworks handle this correctly by default. Express.js (Node) uses express-sessionwith a server-side store; Django stores session data in the database and sends only a signed session key; PHP's built-in sessions write data to the server filesystem. The pattern is always the same: the cookie holds a random identifier, and all sensitive state lives server-side under that key.

   JWT (JSON Web Tokens) are a related technology that encodes claims (including roles and permissions) directly in the token - but crucially, tokens are signed with a secret key. Any tampering with the payload invalidates the signature, so the server can detect and reject modified tokens. However, JWTs have their own pitfalls: the alg: none attack, weak signing keys, and improper signature verification have all been sources of real vulnerabilities. Cookie-based authentication is not inherently weaker than JWTs - both require careful implementation.

Flag

picoCTF{gr4d3_A_c00k13_65fd1...}

Cookie tampering is a common beginner attack; always validate privilege server side.