$ cat writeup.md…
$ cat writeup.md…
broncoctf2026
Task: Express login page whose developers 'forgot to clean up a few things'. Solution: robots.txt leaks a hidden /security route and a base64 blob of usernames; the dev notes reveal passwords are the username reversed, so logging in as admin/nimda returns the flag.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
Welcome to our lovely new login page 💕. The developers swear it's secure… but they may have forgotten to clean up a few things before launch. Can you figure out how authentication works and log in as the right user? P.S. please follow my wishes and do not scrape it...
An Express login page. Two planted hints in the description ("do not scrape it" → robots.txt, "forgotten to clean up" → leftover dev page) lead to information disclosure that reveals the credential scheme. Goal: log in as the correct user and read the flag.
The main page (/) is an Express app (X-Powered-By: Express) serving a "Secure Database" login card. Client-side JS POSTs JSON {username, password} to /login.
The description's "do not scrape it" points at robots.txt:
User-agent: *
Disallow: /security
# amVmZixzYXJhaCx hZG1pbixndWVzdA==
robots.txt is not access control — it leaks both a hidden route (/security) and a base64 comment. Stripping the stray space and decoding:
amVmZixzYXJhaCxhZG1pbixndWVzdA== -> jeff,sarah,admin,guest
Those are the four valid usernames. The "forgot to clean up" hint points to the leaked /security dev notes page, which states:
So the auth scheme is weak by design: password == reverse(username).
...
$ grep --similar