What Is This?

Now that you can run ZAP against your victim (sorry, "target") machine, maximize the application inside the TightVNC window to full screen so you can see it more clearly; then, make a choice about whether you want to save data from your session (a reminder that your ZAP container as it is will shut down unless you make it persistent) and then click Start .

For the target, use your Mutillidae container's IP address or localhost . You can get the IP address of Mutillidae in the same way you learned ZAP's IP address by running the docker ps command and then the docker inspect command, altering the hash to that for the Mutillidae container.

In my case, that means I'll be pointing ZAP at http://172.17.0.2 for Mutillidae (that address is usually the same internally for the first container that's launched, so it's not unusual to see a .2 suffix as the last octet if you started Mutillidae first).

If you're new to proxying through tools like ZAP, you'll probably be pleasantly surprised to discover that inside your container you can even launch a fully fledged version of Firefox to make setting up the proxy easier. Outside of a Docker container, you can also find Firefox plugins that are worth trying in desktop environments if you're keen.

To get the browser working, go to the upper right-hand side of the main Welcome pane, adjust the browser to Firefox (Figure 7), and click Launch Browser . Choosing Chrome doesn't work for me, and the JxBrowser choice sometimes gave me errors, so I went with Firefox.

Figure 7: Fire up Firefox from within your container. Surprisingly that's also hidden away in the ZAP container.

You should see more output in your ZAP terminal window: Low and behold, Firefox appears. Now pop the preferred SQLi login page URL I promised earlier (http://172.17.0.2/index.php?page=user-info.php ) into Firefox, and ZAP will record all the things it sees as it loads the page.

Now you're ready to look at how an attacker thinks in more detail when trying to undermine your application, and therefore its database server. In the following simple example of an attacker sending a crafted URL, the intention is for the server to open a file on the hard drive and display it through the application.

The nasty URL, http://172.17.0.2/index.php?page=%2Fetc%2Fpasswd , should indicate which file is being requested from the server. The result of running such a URL against Mutillidae is shown in Figure 8.

Figure 8: A simple URL tells the server to hand over the /etc/passwd file for scrutiny.

Check It Out

A forward slash in the crafted URL is encoded by %2F , which should get you thinking about how a computer interprets user input. One simple way to test whether a web application is vulnerable to SQLi is to populate an input field (e.g., the login page in Figure 5) with a single quote (apostrophe). If you look below the input boxes, you can see a large amount of SQL being returned (Figure 9). Note the SELECT * FROM accounts … line in particular.

Figure 9: What a difference a single character makes: You can inject your own ill-intentioned data into an application to extract information from the database – or even overwrite the database data.

Essentially, the single quote has confused the application enough to display detailed errors; ultimately, that means that it is not validating its input correctly. A single quote was interpreted as valid input, for example, and revealed the existence of a database table called accounts , among other things. That simple, single quote, then, broke the SQL command, confusing the database server as to what was text and what was SQL.

Ready Player One

After having registered a user and password in the database by clicking Please register here , the single quote is added to the end of an SQL command. I know this because after I registered chris and chris as the username/password combination and then added a single quote to the end of the password, I received the error:

SELECT * FROM accounts WHERE username='chris 'AND password='chris''
That's two single quotes at the end of the line and not a double quote or inverted comma.

If I craft some more data to put into the password input box that changes the way the database server interprets my password, it might SELECT * – that is, display everything in the database table that's called accounts .

To test this, go back to an empty login screen and enter the password

' OR 1='1

with no username. Expect an extra quote to be added at the end of the line by the database server. The result entering that input is: If everything is empty (in the username and password fields) but number 1 equals number 1, then SELECT *.

The good news for the attacker, but the bad news for the company who owns the application, is shown in Figure 10. The output is abbreviated because multiple users were found. Have a closer look in Listing 3 at what the frighteningly simple, appended string of characters changed.

-- the URL that results when user chris logs in --
http://172.17.0.2/index.php?page=user-info.php&username=chris&password=chris&user-info-php-submit-button=View+Account+Details
-- the URL that results from the string of characters that includes the single quote (' OR 1='1) --
http://172.17.0.2/index.php?page=user-info.php&username=&password=%27+OR+1%3D%271&user-info-php-submit-button=View+Account+Details

Figure 10: All your base are belong to us! Barely more than a handful of characters pwned all the users and passwords from the database.

Note that most sites hide the data in the URL using an HTTP POST rather than an HTTP GET, which will reveal submitted information on the URL, but Mutillidae shows the inner workings on the address bar of the browser.

It's worth saying again that this isn't a database problem per se; rather, the application isn't parsing user input correctly (or maybe more accurately, strictly enough), which means a dump of all the data available from the database matching SELECT * is extracted.