Web Application Exploitation and Reporting: Evidence, Impact, and Remediation
This domain tests what happens after a vulnerability is confirmed: controlled exploitation within scope, evidence collection, impact analysis, and a report that a technical and non-technical reader can act on. The exam values reproducibility, professional handling of sensitive data, and clear remediation over dramatic payloads.
Core rules and concepts
- Exploit only far enough to prove impact. Stop before accessing real customer data, deleting records, or using discovered credentials outside scope.
- Preserve evidence: full request and response, timestamps, affected account roles, payload, and the exact URL or parameter. Redact secrets in the final report.
- Chain findings to show business impact, for example SSRF reaching cloud metadata, upload leading to code execution, or IDOR exposing another tenant's records.
- Report structure: executive summary, scope and methodology, findings with CVSS vector and risk rationale, reproduction steps, evidence, remediation, and references.
- Remediation must be specific: parameterized queries, server-side authorization checks, allowlists, output encoding by context, and egress filtering. Avoid vague advice such as sanitize input.
- Clean up artefacts you created, and note any changes made to the target.
Worked example
An SSRF parameter url= accepts arbitrary schemes. Requesting http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns a role name; requesting the role path returns temporary credentials. The reasoning: the first response proves metadata reachability, and the second proves credential exposure. Stop before using the credentials. Report the exact payloads, response snippets, and scope impact, and recommend IMDSv2 plus network egress filtering. Rate the finding critical because credentials could allow cloud account compromise.
Traps that cost marks
- Submitting a finding without a reproducible request or with screenshots that omit the URL and payload.
- Including live secrets, customer data, or tokens in the report without redaction.
- Giving generic remediation such as validate input instead of a control specific to the flaw.
- Exceeding scope during post-exploitation or leaving uploaded files and shells behind.
- Omitting the CVSS vector and the business context that justifies the risk rating.