Having a safe place to try out new security tools is important if you want to stay current with emerging threats and techniques. When testing your Web Application Firewall’s (WAF) ability to mitigate threats, you need a vulnerable target to test attacks against.

This is the first of three articles on testing Web Application Firewalls.

In this first guide, I will step through setting up the Web Security Dojo to provide several weak web applications to attack and configure it for external testing.  I will also show how to configure your attacking machine to access the Dojo, and finally how to perform a basic SQL injection.

Testing Web Application Firewalls with the Web Security Dojo

It seems that everyone is familiar with the infamous Kali Linux which provides a great tool-set to attack a web host. There seems to be less awareness of security targets that are available for testing.

Maven Security Consulting has created a free, open-source, self-contained Virtual Box virtual appliance for this purpose. It is called the Web Security Dojo and is a great target to test against as it contains numerous vulnerable web targets such as:

  • DVWA – Damn Vulnerable Web Application
  • Mutillidae/NOWASP
  • Insecure Webb App
  • WAVSEP Scanner Testbench
  • Juice Shop
  • Gruyere
  • Hacme Casino
  • Webgoat

Getting Web Security Dojo up and running is as simple as installing Virtual Box, downloading the Web Security Dojo virtual appliance and importing the appliance. The site also has more detailed installation instructions to get you going.

Network Architecture for Testing Web Application Firewalls

To be able to effectively test your Web Application Firewall, you need to have it in line with the test machine and the target. As a control, you should also have a test machine that can directly connect to the target without any interference from other devices.

I suggest using a DMZ and internal subnet for this. You want to be able to access the site directly, and via the WAF. I use two attack machines – one on the same subnet, and one on the “external” side of the WAF.

The suggested topology is shown in the diagram below.

Network Architecture for Testing Web Application Firewalls

Make sure the network interface(s) of the test and Dojo machines are bridged to the relevant networks so that it can get a non-NAT IP address. This will simplify testing and troubleshooting. When you dive into packet captures you will also appreciate the simplicity of fewer NATs.

If possible you should isolate the test environment completely from your production network. Introducing fully equipped penetrations testing machines and a purposely vulnerable target on your production network is not a good idea. If you have no other option than using your production environment make sure that you take reasonable precautions during testing and shut down the devices when not in use.

Is your firewall telling simply telling you the URL a threat came from but not what web page someone was one when they URL was loaded? Fastvue Reporter intelligently stitches Internet access logs together to give you a more accurate view of what sites people are accessing when undesirable files are downloaded from. Try the free 30 day trial.

Try Fastvue Reporter Free

Web Security Dojo Configuration

Maven Security packaged and configured the virtual appliance as an all-in-one appliance. So you do not need to connect these vulnerable sites to your network for testing. This is great if you just want to practice with the installed tools in isolation. However, for testing Web Application Firewalls, you need to access it from something other than the 127.0.0.1 localhost. For this, we are going to explicitly change a few of the default settings.

Task 1: Check Network Accessibility

Once your virtual appliance boots up, launch a terminal window and check the IP address with:

# ip a

Confirm that you are in the correct subnet or VLAN that you require. If you are in a subnet without DHCP you can configure static addresses. Using the Start | Settings | Network Connections utility is the easiest.

Task 2: Turn off the host firewalls

By default, the localhost firewall is turned on. Since some of the sites run on non-standard port numbers it is simpler to just disable the firewall.

From the terminal run the following command:

#sudo ufw disable

If prompted for a password, use dojo as the password.

You can check the status of the firewall with the following command:

#sudo ufw status

After testing you could re-enable the firewall with the following command:

#sudo ufw enable

Task 3: Apache restrictive directive configuration

By default, there is an Apache access directive in place to limit access to the Apache hosted site to only allow the localhost. If you attempt to connect from an IP address that is not the localhost you will simply get an error 403 response.

To disable this you need to edit the .htaccessfile. From a terminal shell enter the following:

#sudo nano /var/www/.htaccess

Comment out all of the lines for “limit access to local area network” by adding a # in front of the lines. Ctrl X | Y to save the changes and exit nano.

Apache restrictive directive configuration

To ensure that the changes are applied and persist, restart the virtual appliance with the following command.

#reboot

Attacking the Web Security Dojo

I use a Kali Linux machine as the attacking machine, but using a Windows machine is also perfectly fine. To access the different sites and services on the Dojo machine you will need to have the relevant DNS or HOST entries so that you can generate acceptable HOST headers.

Add the following entries to the relevant file (substituting the correct IP, keep the .local names exactly as they are):

/etc/hosts

or

c:/Windows/Systerms32/Drivers/etc/hosts

192.68.1.10        targets.local
192.68.1.10        docs.local
192.68.1.10        dvwa.local
192.68.1.10        nowasp.local
192.68.1.10        insecure.local
192.68.1.10        wavsep.local
192.68.1.10        juiceshop.local
192.68.1.10        cheese.local
192.68.1.10        casino.local
192.68.1.10        webgoat.local
192.68.1.10        evil.local

Testing LAN Access to the Web Security Dojo

Once the host entries are saved you should be able to connect to the Dojo machine with the following link:

http://targets.local

Web Security Dojo Welcome Screen

This will show you the list of web targets. The top 5 links are sites that are running by default so you should be able to connect to any of them. Targets like Hacme and Webgoat can be manually started on the Dojo machine.

How to Perform an SQL Injection

Injection remains the top most critical web application risk according to OWASP. Injection flaws occur when untrusted data is sent as part of a command or query. The hostile data can trick the application into executing unintended commands or accessing data without proper authorization.

The following test is a very basic SQL injection, but it will allow you to see an exploit being used.

  1. From your test browser connect to the DVWA target
  2. Log in with admin and password
  3. On the left-hand side select DVWA Security
  4. Change the Security Level setting to Low and click Submit
  5. Select SQL Injection
  6. For User ID specify 1 and click Submit. You should now see a single record returned.
  7. Now specify %’ or ‘0’=’0 and click Submit. This should return all 5 record in the database.
How to Perform an SQL Injection

In follow-up articles, I will step through the process of publishing some of the Web Security Dojo sites on the different Web Application Firewall platforms and how to check the WAFs functionality to see if it protects against a simple attack such as the basic SQL injection we used above.

Conclusion

Having a complete environment where you can test web vulnerabilities and mitigating controls is very useful. Not only for testing web application firewalls and training, but also to provide evidence of compliance or provide the proof you need to get a business case approved. It also works as a great awareness tool where you can visually show an audience how simple some exploits are to execute.

NOTE: After your testing is complete I would strongly suggest that you turn off your virtual testing devices. Having weak targets on your network and fully loaded penetration testing devices is a goldmine for an actual attacker!

Did you know: Fastvue Reporter produces clean, simple, web usage reports using log data from your firewall that you can confidently send to department managers and HR team.

What is Fastvue Reporter?