bwapp black-box penetration test

overview

this was the capstone for the cybersecurity half of a two-year program: a simulated professional engagement against bWAPP (BeeBox), an intentionally vulnerable PHP/MySQL application used to train against the OWASP Top 10.

the brief was a black-box test — URL only, no source, no credentials — with the deliverables modelled on what a real client would receive: an executive summary that a non-technical reader can act on, and a technical report that another auditor could reproduce.

what i actually did

the most interesting finding was a full kill chain from a single endpoint:

1. identified an error-based sql injection on a numeric movie= parameter. the application used addslashes() for sanitisation, which broke any quote-based payload. i bypassed it with UNION queries that didn't need quotes — 0 UNION SELECT 1,2,3,... to count columns, then 0 UNION SELECT 1,version(),database(),user(),5,6,7 -- to confirm root-level DB access.
2. extracted credentials from the users table — SHA-1 hashes.
3. cracked the password with john the ripper.
4. logged into phpmyadmin as root / bug using the recovered credentials.
5. discovered a webdav directory with listing enabled, uploaded a php reverse shell.
6. caught a root shell with netcat.

end-to-end: one injected parameter to RCE.

other classes covered

• reflected xss via ajax search bar. the <script> tag was blacklisted; i bypassed it with <img src=x onerror=alert(document.cookie)> and documented a session-hijack PoC.
• stored xss, os command injection, lfi/rfi, and unrestricted file upload — each exploited and written up.
• broken authentication on a login form that used an anti-csrf salt token. i used owasp zap's fuzzer with its anti-csrf token feature to handle the token rotation automatically, with a custom wordlist that combined wfuzz/general/big.txt plus manually appended candidates.
• idor, where the exploit attempt failed — documented as a failed attempt with the observations behind the call. the grading guidance was explicit: a smaller set of vulnerabilities done correctly beats a long list done poorly.

reporting

two documents in spanish, structured around what each audience needs:

• executive summary — visual, non-technical, focused on business impact and remediation cost.
• technical report — per-vulnerability ID, criticality, description, evidence, risks, recommendations, and references. CVE / CVSS / CWE explained in client-readable language rather than copy-pasted.

i added a Limitations section near the end — the instructor flagged this as a grade lever and it reflects how real engagements are documented.

what i'd do differently

the idor endpoint was a missed angle — i tried xxe as an alternative vector and didn't get traction. looking back, i'd spend more time mapping the request flow before pivoting, rather than reaching for a flashy second technique.

i'd also produce the report in english first next time. spanish was the right call for the academic context, but the international cybersecurity market reads english, and the translation pass after the fact slowed me down.