eWPT study materials
eWPT study resources

eWPT: Web Application Vulnerability Identification and Exploitation: Context, Confirmation, Impact

eWPT · Work through your exam, one topic at a time.

All guide sections

Web Application Vulnerability Identification and Exploitation: Context, Confirmation, Impact

This domain tests whether you can identify a vulnerability class, choose a payload that fits the exact context, and confirm exploitability with evidence. You need working knowledge of injection, cross-site scripting, SSRF, XXE, file upload, path traversal, deserialization, CSRF, and business-logic flaws.

Core rules and concepts

  • Identify where input lands: HTML body, attribute, JavaScript string, SQL query, shell command, template, LDAP filter, or file path. The context determines encoding and payload shape.
  • Confirm with the least destructive proof. For blind SQL injection, use time delays or controlled Boolean differences rather than dumping tables. For XSS, prove script execution in a browser and capture the request.
  • Test both reflected and stored variants, and test DOM-based sinks such as innerHTML, eval, and location.
  • For SSRF, distinguish response-based, blind, and internal-only cases; test allowed schemes, redirects, and metadata endpoints only within scope.
  • For file upload, check extension filters, content-type checks, magic bytes, filename traversal, and whether uploaded files are executed or merely stored.
  • WAF bypass is not a goal by itself; understand the filter and use a semantically equivalent payload.

Worked example

A search box reflects q inside an HTML attribute: <input value="TERM">. Sending " breaks out of the attribute. A <script> tag is blocked, but " autofocus onfocus=alert(1) x=" executes when the field receives focus. The reasoning: the context is an attribute, not the HTML body, so an event handler avoids the script-tag filter. Confirm in a browser, capture the exact request and payload, and determine whether the value is reflected or stored. Do not use a destructive payload.

Traps that cost marks

  • Reporting XSS after only seeing an alert(1) without showing the vulnerable request and execution context.
  • Calling SSRF confirmed when only an internal IP is reachable but no response or side effect is demonstrated.
  • Missing blind injection variants because only error-based tests were run.
  • Uploading a web shell or running destructive commands when a benign proof would confirm the flaw.
  • Ignoring chained impact, such as file upload plus path traversal or SSRF plus cloud metadata access.