Security labs: Juice Shop, DVWA and WebGoat

Three sample labs teach web application security by letting a student attack a website that is insecure on purpose: OWASP Juice Shop, DVWA and WebGoat. Each starts in the student’s own copy from a card on the Container page, or as a lab you set in a module, and opens from the lab’s page like any other web service in a lab.

They exist so that students learn how weaknesses work and then build and defend software that does not have them. Every target is inside the student’s own lab copy, and nothing here teaches pointing a tool at a host somebody does not own. A copy has no route to the internet and none to any other student, so the only thing a student can attack is the application the lab started for them.

What the labs are for, and who sees what

These are learning labs for a class, often of students aged 16 and 17, and each one opens by saying the rule: attack your own copy, never a site you do not own. Attacking a system without permission is a crime in the UK under the Computer Misuse Act 1990, so a good first conversation is why the rule exists and what responsible disclosure looks like.

A copy is private to the student who started it. A member of staff who teaches the module can open it to see what the student has done, and opening a student’s work is written to the access log, which the student can read. Nothing in these labs is marked automatically: the student hands in evidence and you mark it, the way you mark any other lab.

The three are third-party programs, run unmodified from the projects’ own public images and not distributed by us: OWASP Juice Shop (MIT licence), DVWA (GPL-3.0) and WebGoat (GPL-2.0). Versions are pinned, so a lab does not change under a class between one lesson and the next.

OWASP Juice Shop

An online shop with over a hundred challenges across the OWASP Top 10: injection, broken authentication, broken access control, cross-site scripting, security misconfiguration and more. Press Open on the lab’s page to see the shop. There is a Score Board that lists every challenge by difficulty and turns each green when it is solved, and it is not linked from anywhere: finding it is the first challenge.

Hints that do not give the answer: look at what the browser sends and receives, read what the page’s own code does, and ask of every input what the program trusts about it. The Score Board’s hints go further, and a student who has tried first learns more from them. The shop forgets its state when the lab stops, so a student who will carry on tomorrow copies the continue code the Score Board offers.

It runs as an unprivileged account in under 512 MB; a small number of challenges that need the internet or an AI service cannot be solved in a lab, which has no way out.

DVWA, the Damn Vulnerable Web Application

One weakness at a time: SQL injection, blind SQL injection, command injection, cross-site scripting (reflected and stored), CSRF, file upload, file inclusion, weak session identifiers, brute force and more. The lab makes the database for the student, so there is nothing to set up: open it and sign in as admin with the password password.

It starts at the low security level. The DVWA Security page raises it to medium, high and impossible, and the same exercise at each level shows what each fix changes and why the easy fix is not enough, which is the point of the lab. The View Source button shows the code at the level in force. The CAPTCHA exercise is not available, because it needs a service on the internet. Stopping and starting the lab gives a fresh DVWA, the same as the setup page’s Create / Reset Database.

WebGoat

A guided course: each lesson explains a weakness, such as injection, broken access control, insecure deserialisation, JWT mistakes or path traversal, and then asks the student to use it, with the lesson marked complete when they do. It suits a first introduction and work set for home.

Open the lab, choose Register and make up a username and password for this copy; the lab has two links, WebGoat and WebWolf, and WebWolf is for the lessons that say to use it. A student’s progress lasts while the lab runs. WebGoat is a Java application and is given 1 GB, the most of the three; it takes a few seconds longer to start than the others.

Setting one for a class

The three are on the Container page’s Sample labs card, where Start runs one for you to try. To set one as work, copy its file into a lab of your own.

  1. Take the file. On the Container page, press Edit the file first on the lab’s card and copy the file. It opens with the rule and the hand-in instructions in its own words.
  2. Make the lab. In your module add a Container lab, choose Written here, paste the file and publish it. Try your own copy first.
  3. Hand it out. Assign it like any task, with a due date if you want one, and say in the task which challenges or lessons to complete.
  4. Mark what is handed in. Open a student’s copy and the evidence they handed in, mark it, and send it back with a reason if it needs more.

What to ask students to hand in

Evidence in two halves. First, proof of the work: a screenshot of the solved challenges on Juice Shop’s Score Board, of each DVWA exercise done at low and again at high, or of each WebGoat lesson marked complete, with the lab’s own address visible in the browser so it is clearly their copy. Second, the understanding: for each, a written explanation in their own words of what the weakness is, the exact input they used and why it worked, what an attacker could do with it, and how the code should have been written. The second half is what tells you whether it was understood or copied from a walkthrough.

For stronger work ask for the fix as well as the attack: the corrected code or configuration for two of the weaknesses, in DVWA by reading what the high level does differently. A short question when you open the copy, such as asking them to solve one challenge again with you watching, is a fair check.

Where each lab sits in a course

The labs cover topics a UK computer science or cyber security T-Level or BTEC unit covers; check your own awarding body’s unit for the exact wording, none of which is quoted here.

Juice Shop: the OWASP Top 10 in a realistic application, threats and vulnerabilities, injection, authentication and session weaknesses, access control, cryptographic failures and security misconfiguration, and vulnerability assessment as a method. DVWA: secure coding and remediation, because the same exercise at four levels is the same code, insecure and then fixed; input validation, output encoding, parameterised queries and file handling. WebGoat: a first introduction to each class of weakness with the explanation beside it, and cryptography, token and deserialisation basics.

All three support the legal and ethical side of the unit: authorisation and scope, the Computer Misuse Act 1990, responsible disclosure and why testing is done on a system you are permitted to test.

Questions people ask

Can a student use these labs to attack a real website?
No. A lab copy has no route to the internet and none to another student’s copy, so the only target is the application the lab started. The brief at the top of each lab says the rule too: attack your own copy and never a site you do not own.
Do the labs mark themselves?
No. Juice Shop’s Score Board and WebGoat’s lesson ticks show the student their own progress, but nothing is sent to you. The student hands in screenshots and a written explanation, and you mark it.
Why do the labs not use the latest version?
Each is pinned to a version we have started and checked, so the same lesson works the same way for every student and for you. The versions move on purpose, not by surprise.
Which labs need the most memory?
WebGoat, which is given 1 GB. DVWA and its database are given 896 MB between them and Juice Shop 512 MB. Each fits inside the 2 GB every lab copy may use.