Includes picoCTF 2022 Solution

Description

1. Step 1Collect the CSS portion

   Observation

   The description talks about the files a page includes, and the setup names style.css as one of them. A CSS comment is invisible on screen while sitting fully intact in the source, which makes the stylesheet the place to look.

   style.css contains the first half of the flag inside a /* ... */ comment. Pull it programmatically with grep -o 'picoCTF{[^ ]*' style.css so you don't have to skim the whole stylesheet. Stop the match at the first space rather than at a closing brace: this half has no }, so a [^}]* pattern would run on and drag the comment's trailing */ along with it.

   What didn't work first

   Tried: Looking at the rendered page source via right-click 'View Page Source' instead of the DevTools Sources tab.

   View Page Source shows the raw HTML document and nothing of the linked CSS or JS. The flag is in style.css, a separate resource, so open DevTools, go to the Sources tab, and read that file.

   Tried: Searching only the Elements panel in DevTools for the flag text.

   The Elements panel shows the live DOM and inline styles, not the contents of an external stylesheet, and the browser strips CSS comments while processing the file, so they never reach that panel at all. The flag sits in a comment in the raw source, visible only in the Sources tab or by fetching the file directly.

   Learn more

   CSS comments use the /* ... */ syntax and are stripped by browsers before rendering - they are intended for developer notes and have no visual effect. However, they are fully visible in the stylesheet source, making them a poor hiding place for any sensitive data.

   Browser developer tools (F12) expose every resource a page loads: HTML, CSS, JavaScript, images, fonts, and network requests. The Sources tab shows each file with syntax highlighting; the Network tab shows every HTTP request and response including headers and payloads. Together they give you complete visibility into everything the server sends to the client.

   This is a fundamental principle of web security: anything sent to the client is visible to the client. Sensitive logic (authentication checks, business rules, secret keys) must live server-side. Hiding data in comments, minified code, or obfuscated scripts provides no real protection against an inspector-equipped browser.

2. Step 2Collect the JS portion

   Observation

   The CSS fragment alone is not a complete flag, and the setup lists script.js alongside style.css. The remaining characters are in a comment inside that second file.

   script.js holds the remaining characters, but the JS comment carries only the tail, with no picoCTF{ prefix, so a flag-shaped grep matches nothing there. Search for the tail instead: grep -o '[^ ]*2of2[^ ]*}' script.js. Concatenate the two halves (CSS first, JS second) to form the full flag. Spreading the flag across two assets is a teaching version of a real ops pattern: split secrets so a single leaked file can't reveal the whole value.

   What didn't work first

   Tried: Submitting just the fragment found in script.js as the full flag.

   The flag is deliberately split across two files, the first half in style.css and the second in script.js, and neither fragment is valid on its own. Concatenate the CSS half first and the JS half second.

   Tried: Searching for the flag in the Console tab output instead of reading the script.js source.

   The Console shows runtime output: errors, console.log calls, evaluated expressions. A comment in script.js is never executed and never printed, being static text in the source. Open the Sources tab, select the file, and read it.

   Learn more

   JavaScript comments use // for single-line and /* */ for multi-line, identical to CSS and similar to most C-family languages. Like CSS comments, they are sent to the browser as part of the response and are fully readable in DevTools - or by simply fetching the file with curl or wget.

   Splitting the flag across multiple files adds a small layer of friction - you have to look in two places instead of one. In real security assessments, sensitive data is sometimes split across config files, environment variables, and databases in an attempt to limit exposure if any single file leaks. But when all the pieces are on the same server and served to the same client, the protection is minimal.

   Challenges like this one train the habit of thoroughly reviewing all assets a page loads, not just the HTML. In real web pentesting, JavaScript files frequently contain API keys, internal endpoint URLs, authentication tokens, and developer comments describing security controls or internal architecture. For more failure modes in the same shape, see Web challenges: real-world bug patterns.

Flag

Anything sent to the client can be recovered, so never trust obscurity inside frontend assets.