This challenge starts with a login page, so the natural first thought is to test the authentication flow and see whether the validation happens on the server or in the browser.
The page asks for a username and password and appears to reject special characters, allowing only letters and numbers. That often suggests some kind of input filtering, but it does not necessarily mean the backend is secure.
Inspecting the initial page source does not reveal anything useful. There are no obvious hardcoded credentials and no direct flag exposure in the HTML.
Trying a basic SQL injection payload also fails, which tells us this challenge is probably not about bypassing a database query. When that happens, it is worth shifting focus from the HTML source to the linked JavaScript files.
One file stands out: secure.js. That is the real clue in this challenge.
Inside secure.js, the valid credentials are exposed directly in client-side code. This means the browser already has everything needed to pass the login check, which also means an attacker can read the same data by opening the script.
Why This Works
The vulnerability here is insecure client-side authentication logic. If the application trusts values hardcoded in JavaScript, anyone can recover them because browser code is never secret.
In other words:
- The login logic is exposed to the user.
- The valid credentials are stored in a readable script.
- No real server-side protection prevents reuse of those credentials.
Solving the Challenge
We simply take the credentials from secure.js and use them in the login form.
After logging in with those values, the page reveals the flag. The main takeaway is that authentication must always be enforced on the server side, not hidden in browser JavaScript.