Exploring Web App Vulnerabilities & Reporting
Overview In this lab, I explored common web application vulnerabilities using WebGoat and bWAPP alongside common penetration techniques and OWASP ZAP for scanning. This wasn’t just about checking boxes — it was an opportunity to think like an attacker while documenting my process like a defender. I walked through identifying, verifying, and reporting issues that could realistically exist in production environments. **Note** This lab was completed on July 14th 2025.
Focus This hands-on task focused on utilizing and understanding common web application vulnerabilities — specifically SQL Injection, Cross-Site Scripting (XSS), and Cross-Site Request Forgery (CSRF). I used OWASP WebGoat and bWAPP as intentionally vulnerable apps and OWASP ZAP as a primary tool to simulate attacker behavior and learn about detection, exploitation, mitigation, and reporting and how they can be used.
Setup
- Installed WebGoat via Docker on Windows, then again natively on Kali Linux
- Installed bWAPP on Kali Linux
- Configured OWASP ZAP for both manual and automated scanning
- Enabled HUD (Heads Up Display) in ZAP for interactive in-browser testing
- Verified VM network connectivity for proper traffic monitoring
- Used Firefox Developer Tools and Wireshark for deeper HTTP inspection if needed
Vulnerability Investigation
Once the environment was up and running, I began testing vulnerabilities across both platforms. ZAP was configured to spider and actively scan each application while I simultaneously worked through guided WebGoat lessons to understand the background mechanics behind each vulnerability — learning foundational knowledge for these attacks.
SQL Injection
- Exploited weak query handling in WebGoat’s login module using payloads such as
' OR 1=1 --to bypass authentication - In bWAPP, used search-based injections (e.g.
' OR 1=1 #) to dump backend data - ZAP confirmed these vectors automatically with alerts like SQL Injection
Cross-Site Scripting (XSS)
- Injected payloads like
<script>alert("XSS")</script>into input fields in WebGoat and bWAPP - ZAP flagged many vulnerable JS libraries and reflected input
- Successful alert pop-ups demonstrated impact of unsanitized user input — and possibility for more malicious use
Cross-Site Request Forgery (CSRF)
- ZAP identified missing anti-CSRF tokens in multiple WebGoat requests
- Followed up with WebGoat’s CSRF module to simulate forged state-changing actions without authorization **See full write-up linked at the end of this post**
Key Takeaways
- Input validation alone is not enough as more modern context-aware protections like tokens, encoding, and parameterized queries are vital
- Automated tools like ZAP are useful, but manual verification is essential to confirm real impact and weed out false positives (ZAP produces many)
- These vulnerabilities can certainly be chained together by threat actors to escalate access or pivot within a system
Next Steps as a defender If this were a real environment:
- Implement input sanitization and parameterized queries to eliminate injection risks
- Add output encoding, input validation, and CSP headers to mitigate XSS
- Enforce anti-CSRF tokens on all state-changing requests
- Introduce regular dynamic application scans and manual testing cycles
- Integrate findings into a SIEM platform like Splunk for centralized alerting
Final Thoughts
This lab reinforced just how dangerous even basic web vulnerabilities can be when left unchecked. SQLi can expose sensitive backend data, XSS can lead to full session hijacking, and CSRF can silently execute actions. While the apps I tested were purposefully insecure, the techniques used are very real and have proven to be very common in active attack campaigns.
More importantly, the exercise helped me think like both attacker and defender. Not just finding vulnerabilities, but understanding why they matter, how to manually confirm them, and how to clearly document them.
Full PDF Report & Screenshots:
