WebGoat and bWAPP Walkthrough: Key Lessons Solved

Part of our free Tools & Targets series. Hands-on guides to the vulnerable practice apps and the security tools you will use on the job. Pair it with our Build Your Own Cyber Lab series for the lab to run them in.

1. Vulnerable practice apps: DVWA, bWAPP, Juice Shop, WebGoat, AI Goat and more
2. DVWA walkthrough: every module solved at Low, Medium and High
3. OWASP Juice Shop: beginner and intermediate challenges solved
4. WebGoat and bWAPP: key lessons solved (you are here)
5. Threat modeling your lab with OWASP Threat Dragon
6. Nessus Essentials: vulnerability scanning your lab
7. Snort and Suricata: network IDS and your first rules
8. Splunk in your lab: install, forward Windows logs, search with SPL
9. Wazuh deep dive: file integrity, vulnerability detection and custom rules

Part A: WebGoat

WebGoat teaches before it tests: each lesson has pages of explanation followed by exercises checked by the server. Read the explanation pages - the answer is usually one of the examples, adapted. Lesson numbering and wording change between releases, so the solutions below describe the pattern that solves each exercise; if a page differs, the pattern still applies.

SQL Injection (intro)

The first exercises teach SQL itself against an employees table:

• Retrieve data (DML): a plain SELECT, for example SELECT department FROM employees WHERE first_name='Bob' AND last_name='Franco' - use the names the exercise gives you.
• Modify data (DML): an UPDATE ... SET ... WHERE for the employee named in the task.
• Change the schema (DDL): ALTER TABLE employees ADD phone varchar(20).
• Grant rights (DCL): a GRANT statement giving the named user access to the named table.

Then the injection exercises:

• String injection: the query is built as ... WHERE last_name = ' + input + '. Choose the combination that makes the condition always true, equivalent to Smith' or '1' = '1.
• Numeric injection: a numeric field is not quoted, so 0 or 1=1 in the injectable field returns every row. Try both fields to find which one is concatenated rather than parameterised.
• Compromising confidentiality: close the string and add an always-true condition to the authentication field, e.g. ' OR '1'='1, to see every employee's salary.
• Compromising integrity (query chaining): end the first statement and append your own, for example '; UPDATE employees SET salary=99999 WHERE first_name='John'-- with the name the exercise uses.
• Compromising availability: chain a statement that removes the evidence: '; DROP TABLE access_log--.

Fix (the Mitigation lesson): prepared statements with bound parameters, and least-privilege database accounts so even a successful injection cannot DROP or GRANT.

Cross-Site Scripting

• The reflected exercise echoes a shopping-cart field (often the credit-card number) back unencoded: <script>alert('xss')</script> there.
• The DOM-based exercises ask you to find a test route left in the JavaScript (search the client code for "test" routes) and call a function through it.
• Fix: output encoding for the context, and a Content Security Policy.

Broken Authentication and Access Control

• Authentication bypass: the security-question flow trusts the parameter names it receives. Intercept the request and rename or remove the question parameters so the server checks nothing.
• Insecure Direct Object References: log in as the given user, view your profile, then change the profile id in the request to view and edit another user's profile.
• Missing function-level access control: hidden menu items are present in the HTML; find them, and call the admin endpoints directly.
• Fix: server-side checks on every request, object-level authorisation, and never relying on hidden UI.

Use WebWolf

Some lessons (password reset, XXE, SSRF-style exercises) need an attacker-controlled server. WebWolf on port 9090 provides a mailbox, file hosting and a request log - check it after sending payloads.

Part B: bWAPP

bWAPP lists its bugs in a drop-down grouped by OWASP category, each with low / medium / high security levels. The method is the same as DVWA: solve at low, then raise the level and work out what the new filter missed.

Good bugs to start with

• SQL Injection (GET/Search): search for a movie with ' or 1=1-- - to list everything, then ' union select 1,2,3,4,5,6,7-- - to find the column count (adjust until the error goes away) and replace numbers with user(), database() or columns from the users table.
• OS Command Injection: the DNS lookup field accepts www.example.com; id at low.
• HTML Injection - Reflected (GET): <h1>injected</h1> in the name fields shows the page renders raw HTML, which leads straight to XSS.
• XSS - Reflected (GET): <script>alert(1)</script> at low; try event-handler payloads as the level rises.
• Insecure DOR (Change Secret): intercept the request and change the login parameter to another user.
• Local / Remote File Inclusion (RFI/LFI): the language parameter loads files; ../../../../etc/passwd at low.
• Heartbleed and Shellshock (bee-box only): the bee-box VM runs deliberately old server software so you can practise these famous CVEs safely with the Metasploit or nmap scripts.

At medium and high

bWAPP's medium level typically adds escaping (addslashes) or simple blacklists, and high uses proper functions such as mysqli_real_escape_string with quoting or htmlspecialchars. When a bug cannot be exploited at high, read why - that is the fix you would recommend in a report.

Keep it in the lab

These apps are deliberately vulnerable. Run them only on an isolated lab network or bound to localhost, never on a server reachable from the internet, and only use these techniques against systems you own or are authorised to test.

Next step

Part 5 switches from breaking apps to designing them safely: threat modeling with OWASP Threat Dragon.