In the past few years I have done several web application firewall assessments and have been very successful in bypassing them. So, thought to share some of the things that I learnt.
Let me just clarify what this post is NOT about: This post is not about, how to detect web application firewall (WAFs) on remote servers. You can easily do that using wafw00f.
This is more about the methodology, when you are asked to assess the effectiveness of a WAF product which is to be installed on the client side. In this case you already know which product it is, and then you start poking and start finding what it blocks and how it can be bypassed.
Usually devices aren’t assessed, they are just reviewed, that is, the assessors ask for a configuration of the device and then that is reviewed. My approach is a little different, I want to be 100 percent sure, that the WAF does what it says.
In order to assess a WAF, the assessor should be able to see the result of every attack which he/she makes. And to see if it gets through or not, in real time. This is where the initial setup comes in, which is to be setup by the client before you start the assessment.
Setup
The best and most practical setup for this assessment is to install a vulnerable application behind the WAF, of the client and start pentesting the application.
So in other words: YOU <——-> |WAF| <——–> Vulnerable application
What to look for?
I noticed that most of the vendor based WAFs have modsecurity integration in one form or another. What you should start with is to ask the client to set the most strict rules on the WAF and then start pentesting the vulnerable web application.
Some of the WAFs only have two options Normal or Strict and there is no option to add custom rule-sets. Though I won’t name the vendor but it was a surprise to us as 90% of the attack payloads went through the firewall, even at it’s Strict setting.
So, if you see a WAF with no custom settings (rule-set adding/editing) then that is a problem in itself. Do ask the client about that (explicitly), because the people managing the WAF would not be able to do anything if the bypasses happen.
Against another, very well known name, the SQL injection payload, [‘or’1’=’1], was blocked but [‘or’?’=’?] went through like a pro. In the meeting even the guys working at the vendor were surprised to see it get bypassed. Pretty simple stuff but it works.
I can give a detailed comparisons of the major players in the WAF world, but I think I will wait for another time.
There might be other ways/methodologies for doing this kind of an assessment, but I trust this way. If you only do a configuration review, the problems which are inherent in the WAF product would still remain. The example is that of the one mentioned above, the one having only two options and no way to edit the rules. If an assessor just does a configuration review of that WAF, they will give it a gold star, when they see that the WAF is set to Strict and it is working perfectly.
Do try it, you might find some awesome bypasses. Many of you, independent researchers, might be using the same methods for finding out bypasses, so keep up the good work!
Peace!