Local Authority

Description

Solution

1. Step 1Enumerate hidden assets
   Open login.php directly (e.g., http://saturn.picoctf.net:64710/login.php). The browser now lists secure.js among the sources.
   Learn more

   Asset enumeration is the process of discovering resources on a web server that aren't explicitly linked from the main page. Common techniques include reading the page source for referenced URLs, checking robots.txt and sitemap.xml, and using directory brute-forcing tools like gobuster or dirsearch to probe for common filenames.

   Here, the form action attribute in the main page's HTML points to login.php, which is enough of a breadcrumb. Manually navigating to that URL loads it in the browser, which in turn causes the browser to request all scripts and stylesheets referenced by login.php - including secure.js. This is a reliable way to discover secondary resources: follow every link, form action, and script reference you find.

   In real web application testing, this reconnaissance phase is critical. Tools like Burp Suite's Spider, OWASP ZAP's crawler, or wget --mirror can automate the discovery of linked resources across an entire site.

2. Step 2Read secure.js
   secure.js contains `const user = "robert"; const pass = "hannah";` (values may vary). Use them on the main login form.
   Learn more

   Storing credentials in client-side JavaScript is a severe security vulnerability. The entire purpose of authentication is to distinguish authorized users from unauthorized ones - but if the password is in the JavaScript file that every visitor's browser downloads, any visitor can read it. This type of vulnerability is so common that browsers' built-in developer tools are sufficient to exploit it: no specialized tools required.

   A "secure" filename for a JavaScript file containing cleartext credentials is ironic, but this naming pattern (trying to obscure the purpose through the filename) is a form of security through obscurity - it provides no actual protection. The real fix is to perform authentication server-side: the server compares submitted credentials against a hashed value in a database, and the client never sees the reference value.

   This pattern also illustrates why Single Page Applications (SPAs) that implement authentication logic in JavaScript are inherently limited: you can gate the UI, but you can never gate the data if the same JavaScript file is accessible to all users.

3. Step 3Retrieve the flag
   Successful authentication redirects to admin.php, which prints the picoCTF flag in plain text.
   Learn more

   Once you have the credentials from secure.js, logging in is straightforward. The server-side authentication check validates the submitted credentials and, if they match, grants access to the admin page. Even though the validation happens server-side, the credentials were exposed client-side - making the server-side check irrelevant from a security standpoint.

   This challenge models a real attack pattern: credential harvesting from client-side code. Security researchers regularly find API keys, database passwords, and auth tokens embedded in JavaScript bundles shipped to browsers. Tools like truffleHog and gitleaks scan codebases for such accidental exposures, and browser extensions like DotGit look for exposed .git directories that might reveal source code and embedded secrets.

Flag

picoCTF{j5_15_7r4n5p4r3n7_b0c...}

Because the credentials live in front-end JavaScript, simply browsing to the referenced file is enough.