Web Application Testing
This domain tests white-box web exploitation: reviewing application source, tracing attacker-controlled data to dangerous sinks, and writing a reliable exploit chain rather than firing off scanner payloads. You are expected to understand framework routing, authentication and session logic, and how small logic flaws combine into high-impact access.
Core rules and concepts
- Start from entry points: routes, controllers, API handlers, middleware, and serializers. Map which inputs reach sinks such as SQL, template engines, file APIs, process execution, deserialization, and redirects.
- Prefer source-to-sink reasoning over black-box guessing. Note validation order, canonicalization, encoding, and where trust boundaries actually sit.
- Authentication bypass often comes from inconsistent checks: one route checks a role, another checks only a session flag, or a token is verified loosely.
- Exploit chains matter. A low-impact open redirect can steal a token; a weak secret can forge a session; a file read can expose credentials.
- Write scripts that reproduce the exploit end to end. Handle CSRF tokens, cookies, redirects, and content types explicitly.
Worked example
A Flask route accepts a name parameter, applies a blacklist that removes {{ and }}, then calls render_template_string. The reviewer notes that Jinja block tags are not filtered and that the rendered output is returned. Rather than assuming the blacklist is sufficient, trace the input to the template sink and test an alternate expression context that does not require double braces. The reasoning is: source is user input, sink is template evaluation, and the control is an incomplete string filter. A robust exploit uses a block-level construct to evaluate an expression and reads the response to confirm execution. If output is not reflected, the chain moves to a blind evaluation or file-write primitive.
Traps that cost marks
- Treating a filtered payload as a dead end instead of testing encoding, alternate syntax, and parser differences.
- Missing that a vulnerability exists in a helper function called by many routes.
- Forgetting that the exploit must work against the deployed configuration, not just local debug mode.
- Failing to preserve session state and CSRF tokens across requests.