Includes picoCTF 2022 Solution

Description

1. Step 1

   Collect the CSS portion

   Observation

   I noticed the challenge description mentioned 'files it includes' and the setup steps called out style.css as one of the assets, which suggested the flag was embedded as a comment inside the stylesheet since CSS comments are invisible on screen but fully present in the source.

   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.

   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 but not the linked CSS or JS files. The flag is hidden in style.css, which is a separate resource. You need to open DevTools, go to the Sources tab, and navigate to the style.css file to see its contents.

   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 external stylesheet files. CSS comments are stripped when the browser processes the file, so they never appear in the Elements panel at all. The flag is inside a comment in the raw style.css source, which is only visible 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 2

   Collect the JS portion

   Observation

   I noticed the CSS fragment alone did not form a complete picoCTF{...} flag, and the setup steps listed script.js as a second asset alongside style.css, which suggested the remaining characters of the flag were hidden in a comment inside script.js.

   script.js holds the remaining characters. grep -o 'picoCTF{[^}]*' script.js pulls the second fragment; 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 - style.css holds the first half and script.js holds the second half. Neither fragment alone is a valid flag. You need to concatenate the CSS fragment first and the JS fragment second to get the complete picoCTF{...} value.

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

   The Console tab shows runtime output - errors, console.log calls, and evaluated expressions. A comment in script.js is never executed or printed; it is just static text in the source file. To read it, open the Sources tab, select script.js, and read the raw file contents.

   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-never trust obscurity inside frontend assets.