Mutillidae lab: practise SQL injection and XSS on a vulnerable PHP web application

OWASP Mutillidae II is a PHP website that is insecure on purpose, with the OWASP Top 10 and more built into it: SQL injection, cross-site scripting, command injection, LDAP injection and many others, with hints on each page. This lab starts it, with its database and its LDAP directory, in each student’s own private copy.

Every target is inside the student’s own lab copy, which 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. The rule is said at the top of the lab: attack your own copy, never a site you do not own.

What students learn

The OWASP Top 10 in a realistic website, with a lot of weaknesses to choose from. The site has a security level, 0, 1 and 5, that its menu steps through, so the same exercise can be done again to see what the fix changes: a name injected into the user lookup finds every account at level 0 and none at level 5. It suits an introduction to web security or secure coding: input validation, output encoding, parameterised queries, authentication and sessions.

Run it in your browser

The lab makes the database for the student, so there is nothing to set up, and it says it is running only once the site works.

  1. Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
  2. Find the lab. The Sample labs card lists every sample. Find OWASP Mutillidae II.
  3. Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
  4. Open it. On the lab’s page, press Open. The top of every page shows the security level, which starts at 0. Sign in as admin with the password adminpass for the pages that ask for an account. Toggle Hints and Toggle Security are in the menu. Stopping and starting the lab gives a fresh site, the same as Reset DB.

What to ask students to hand in

A screenshot of each exercise solved, with the lab’s own address visible, and for each a written explanation in their own words of what the weakness is, the input they used, why it worked and how the code should have been written. For stronger work ask for the same exercise at level 5 as well and what the code does differently there.

A basic lesson on this lab

Mutillidae Basics is a small lesson worked in this lab, starting with the rule that a student attacks their own copy and nothing else. From the terminal they sign in with curl, look up one account by name, change the name so the lookup finds every account, and then raise the security level and see the same input find nothing.

A free personal account is given them on the Basics module, which is on Home, every college can copy it from the Library’s Basics folder, and a new college opens with it in a module called Lab Basics (Sample). It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

The code on GitHub

The compose file runs the Mutillidae project’s own three public images, one each for the website, its MariaDB database and its LDAP directory, each pinned by version and digest and run unmodified. Mutillidae is GPL-3.0 licensed and belongs to its authors, and it is not distributed by us. The lab has no way out to the internet, so anything that fetches a page from another website has nothing to reach.

Set it as work

Say in the task which exercises to complete and what to hand in.

  1. Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-mutillidae with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it.
  2. Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start 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 what to do and what to hand in.
  4. Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Questions people ask

What are the sign-in details?
admin with the password adminpass, the same in every copy, and anybody can make another account on the Login/Register page. A copy is private to the student who started it, and nothing outside it can reach it.
Why does the site go back to the start after a restart?
The database is made fresh each time the lab starts and is not saved, so a site broken by an exercise is cured by stopping and starting the lab, or by choosing Reset DB in the menu.
Why does it need so much memory?
The lab is three programs, the website, its database and its directory, limited to 512, 384 and 256 megabytes. The three together use about 210 megabytes when idle, well inside a copy’s allowance.