BrOWSER BOSS FIGHT — UMass Cybersecurity CTF

Description

Organizer description was not preserved in the local task files.

English summary: the landing page presented a password form, but browser JavaScript silently replaced any submitted value with a fake key. After bypassing that behavior with a direct request, the second stage relied on a client-controlled cookie for authorization, which could also be tampered with to obtain the flag.

Analysis

The first page at / contained a form posting to /password-attempt. Recon also showed inline JavaScript that overwrote whatever the user entered with WEAK_NON_KOOPA_KNOCK before submission, so solving the challenge from the browser alone would always send the wrong secret.

The response headers exposed an additional clue: King Koopa, if you forget the key, check under_the_doormat!. That strongly suggested the real key was under_the_doormat, and the JavaScript was only a client-side obstacle.

Sending a direct POST request to /password-attempt with key=under_the_doormat bypassed the JavaScript entirely and granted access to /bowsers_castle.html. That page then set multiple cookies, including hasAxe=false.

The castle page text explained that Bowser had removed the axe, which is exactly the sort of state that should never be trusted when it is stored in a client-controlled cookie. Re-requesting /bowsers_castle.html with hasAxe=true changed the server response and returned the flag page.

The core lesson is simple: never trust client-side JavaScript or client-controlled cookies for access control. Anything enforced only in the browser can be bypassed, and any state stored on the client can be modified.

Solution

...