This is a case study of the ModSecurity Web Application Firewall using the OWASP Core Rule Set.  In this case study we will be testing many XSS attacks in order to find out what gets past our WAF filter and what does not.

In this test we are running an Apache web server on Ubuntu with ModSecurity.  Below is the link I used to setup ModSecurity.

How To Set Up ModSecurity with Apache on Ubuntu 14.04

We will use a very simple PHP page to test out our XSS attacks below.  This simple page just takes a ‘name’ parameter and reflects it on the screen.

Example of test.php

test.php source code:

<html><body>Hello, <?php echo $name; ?>!</body></html>

For the XSS Fuzzing lists, we will be using lists from Daniel Miessler’s SecLists Github site, which contains a massive list of various security information.  I highly recommend checking it out.  Below is his description of SecLists:

“SecLists is the security tester’s companion. It’s a collection of multiple types of lists used during security assessments, collected in one place. List types include usernames, passwords, URLs, sensitive data patterns, fuzzing payloads, web shells, and many more. https://www.owasp.org/index.php/OWASP…”

Test #1

For this test we will be using the XSS list from SecLists below:

https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/XSS-RSNAKE.txt

Below are our results using Burp Suite Intruder.

Note the status column and the status code.  With it sorted we only have one 200 status code, which is blank and invalid.  The 200 status code means ‘OK’, which is used to tell us the page loaded without error.  The 400 error codes mean ‘Bad Request’, which means the request could not be understood by the server.  The 403 error code means ‘Forbidden’ – these are the XSS attacks that have been blocked by ModSecurity.

HTTP Error Codes.

The 400 error coded XSS attacks have got through the Web Application Firewall (WAF), but were not able to be interpreted by the server, thus we do not have an XSS vulnerability.  If we did, it would have a 200 status code.

The fact that we have only one 200 status code with the blank XSS attack means that ModSecurity has blocked all the XSS attacks that we have thrown at it using this XSS attack list.

Blocked XSS attack with ModSecurity in the Browser:

Blocked XSS attack with ModSecurity shown in the server log:

Test #2

For this test we will be using the XSS list from SecLists below:

https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/XSS-BruteLogic.txt

Below are our results using Burp Suite Intruder.

For this test we have a number of XSS attacks that have gotten through our WAF, but they also did not generate an XSS attack.  The 200 status code tells us that there were no errors, but after manually investigating some of these URL’s the command injected but did not execute on the web server.  Perhaps on other web platforms these could work?

Test #3

For this test we will be using the XSS list from SecLists below:

https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/XSS-JHADDIX.txt

Below are our results using Burp Suite Intruder.

It looks like ModSecurity blocked all the XSS attacks from this attack list, as the only 200 status code we have is from the blank space on top of the attack list.

Summary

ModSecurity has options to load more advanced Core Rule Sets if they are purchased with a subscription, but it looks like in our case the basic free list works just fine.

Here is a link to the ModSecurity CRS.

On their website it states the OWASP CRS Protects against the following:

One thing that I noticed is that this ruleset does not protect against Command Injection attacks.  See below:

 

Another ModSecurity rule set would be needed to stop command injection attacks like these.