CTF Web Challenges skill for Codex

A CTF web challenge is a puzzle with an intended solution. Solve it by understanding the app, not by firing every tool at it. Done well means: you can explain the vulnerability, reproduce the flag from your notes, and you learned the bug class well enough to recognise it next time.

Scope

Only touch the challenge instance you were assigned (the lab’s own hosts, your container, the competition’s scoped targets). CTF authorization ends at the challenge boundary: scanning the platform itself, other teams’ instances, or unrelated internet hosts is out of bounds. If a “challenge” points at a real third-party site, stop.

Method

- [ ] 1. Map the app: every route, parameter, cookie, header, and client-side JS
- [ ] 2. Read the source if given (challenge handout, /src, a .git folder, JS bundles)
- [ ] 3. Identify the trust boundary and the likely intended bug class
- [ ] 4. Form one hypothesis; test the smallest thing that confirms or kills it
- [ ] 5. Build the exploit step by step; keep every request/response in notes
- [ ] 6. Get the flag; write up the chain while it is fresh

1. Map

• Walk the app as a user. Note auth flows, roles, object IDs, and anything that looks server-rendered from input.
• Read the JS: fetch/axios calls reveal hidden endpoints and parameter names. Source maps (.js.map) often ship the original code.
• Check the obvious leaks: /robots.txt, /.git/ (dumpable with git tooling if exposed), /.env, backup files (index.php~, .bak), verbose errors, and comments in HTML.
• Diff responses: a valid vs invalid username, an admin vs user token, a 200 vs 403.

2. Recognise the bug class

Clue	Likely class	First probe
Numeric or guessable object IDs in URLs	IDOR / broken access control	Request another ID with your session
Your input appears in the rendered page	XSS, or SSTI if a template engine	{{7*7}}, ${7*7}, <%= 7*7 %> per engine
Input reaches a SQL-looking query; errors change on '	SQL injection	Boolean/time-based differentials; use the DB’s own syntax
A JWT in a cookie or header	Alg confusion, alg:none, weak secret, kid tricks	Decode header/claims; check signature handling
Serialized blob (base64 of pickle/PHP/Java/Node)	Insecure deserialization	Identify the format before anything else
__proto__ / constructor accepted in JSON	Prototype pollution	Pollute a benign key, look for a gadget
Login logic in provided source	Auth logic flaw	Trace the comparison and the session issuance
Weird header handling / proxy in front	Request smuggling, cache poisoning, host-header	Compare front-end vs back-end parsing

PortSwigger’s Web Security Academy has a focused lab for each of these; when a class is unfamiliar, work the matching lab first, then return to the challenge.

3-5. Confirm, then build

• Change one variable at a time. A confirmation probe should give an unambiguous yes/no (reflected 49, a boolean-differentiated response, an out-of-band callback you control).
• Keep a running log: request, response, what it proved. This is the write-up and the thing that lets you backtrack when a path dead-ends.
• Use a proxy (Burp, mitmproxy) to replay and tweak requests; curl with saved cookies for scripting the final chain.
• Out-of-band confirmation (blind SSRF/SQLi/SSTI) uses a collaborator/interactsh-style listener you control, never a victim’s infrastructure.

Tools, used with intent

• Recon: browser devtools, ffuf/feroxbuster for content discovery (only on the scoped host), nuclei to catch known patterns fast.
• Intercept and replay: Burp Suite (Repeater, Intruder) or Caido; mitmproxy for scripting.
• Decode and inspect: CyberChef for encodings, jwt_tool or manual base64 for tokens.
• These need network and sometimes installs; in the Codex sandbox, call out when a step needs network or approval. Rate-limit discovery tools so you do not knock the challenge over.

Getting unstuck

• Re-read the source and the challenge description; CTF titles and flavour text hint at the class.
• The intended bug is usually one hop, not a five-stage chain. If your plan is elaborate, you probably missed something simpler.
• Compare with a known-good request to see what you are missing (a header, content type, ordering).
• Diff the app against the framework’s defaults: what did the author deliberately change?

Write-up template

## <Challenge name> (category: web, points: N)
**Bug class:** SSTI in the Jinja2 profile renderer
**Entry point:** POST /profile, field `nickname`, reflected into the rendered page
**Confirmation:** `{{7*7}}` rendered as `49`
**Exploit chain:**
1. `{{config}}` leaks app config -> SECRET not there
2. `{{''.__class__.__mro__[1].__subclasses__()}}` to reach a RCE gadget (sandboxed)
3. Read the flag file via the gadget
**Flag:** flag{...}
**Lesson:** user input rendered through a template engine without autoescape/sandbox