This is a case study of the Sucuri Web Application Firewall (Basic Plan). 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 Securi as the WAF.

We will use a very simple PHP page to test out our XSS attacks below.

Below is the web page PHP code:

<?php
echo '<b>Command Injection Test:</b> ';
print_r('<br /><br />');
print_r('Syntax: /command.php?cmd=[command]');
print_r('<br /><br />');
print_r('Example: www.example.com/command.php?cmd=cat /etc/passwd');
print_r('<br /><br />');
print_r($_GET);
print_r('<br />');
print_r('<br />');
print_r('<u>Result:</u>');
print_r('<br />');
print_r('<br />');
system($_GET['cmd']);

The important line here is system($_GET['cmd']); as this is the line that will send the input to the command interpreter of the Linux webserver.

Below is the command.php page when it first comes up before any input:

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 a few 200 status codes, which do not process as command on the server, and are 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 Sucuri.

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 have a few 200 status codes 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 Securi in the Browser:

Below is the message we receive in our browser when we try to browse the protected site with the blocked XSS attack.

Signing into our account on the Sucuri website, we can also see the attack was blocked and logged.

Finally, the Sucuri site shows us a summary of blocked attacks and their types.

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 Sucuri 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

Sucuri has other security packages that the basic one we used here.  It looks like the basic package is all we need though as no valid XSS attacks got through to the server.