Cracking the Code: The Ultimate Guide to the OSWE Exam Report

Title (e.g., “SQL Injection in viewUser.php”)

Affected file & line
/modules/user/viewUser.php – line 42

Code snippet

$id = $_GET['id'];
$query = "SELECT * FROM users WHERE id = " . $id;

Description
No input sanitisation. $id concatenated directly into query.

Proof of Concept
Request:

GET /viewUser.php?id=1 UNION SELECT password FROM admins

Response showing admin hash.

Impact
Database disclosure, authentication bypass, potential RCE if combined with file write.

Repeat for each distinct vulnerability (e.g., File Upload Bypass, Command Injection, Auth Bypass).

Recommended Report Structure

1. Executive Summary

   • One-paragraph scope and high-level findings (impact, number of critical issues, overall assessment).

2. Environment

   • Target hostname/IPs, application stack (web server, language/framework, DB), exam time window, tools used (e.g., Burp Suite, ffuf, nmap, sqlmap, custom scripts).

3. Methodology

   • Recon steps (enumeration, crawling), testing approach (blackbox/graybox assumptions), and exploitation strategy.

4. Vulnerability Findings (repeat per issue)

   • Title & Severity: (Critical/High/Medium/Low)
   • Affected Component: URL, parameter, endpoint, or file path.
   • Description: What the vulnerability is and why it matters.
   • Impact: Potential attacker capabilities (RCE, auth bypass, data leak).
   • Proof-of-Concept: Concise, reproducible steps with exact requests, payloads, and expected responses. Include command output, screenshots, or base64-encoded artifacts as appendices.
   • Root Cause: Code or configuration causing issue.
   • Remediation: Specific fixes, secure coding examples, configuration changes, and testing recommendations.
   • References: CVE, OWASP links, or docs for similar issues.

5. Chaining & Post-Exploitation

   • Show how multiple issues combine to achieve higher impact (e.g., SSRF -> internal service access -> authentication bypass).
   • Steps to achieve final objectives (proof files, flags). Include precise commands and timings.

6. Evidence Appendix

   • Full exploit scripts, raw request/response logs, screenshots, file hashes, and final flags. Ensure sensitive data redaction as required by exam rules.

7. Mitigation & Hardening Checklist

   • Actionable items prioritized by severity (patching, input validation, least privilege, logging/monitoring, WAF rules).

8. Testing Notes & Limitations

   • Assumptions, test coverage, any parts of the app not reachable during exam window.

The "No Fail" Checklist for your PoC:

• [ ] Does it work on a fresh target?
• [ ] Does it work if run twice consecutively?
• [ ] Does it run on a standard Kali Linux install (no custom libraries except requests)?
• [ ] Does it print the flag/shell output to stdout?