WAF and your penetration test

Your penetration tester wants you to disable your web application firewall (WAF) or white list their IP. Do you do it? Should you do it?

This question gets asked all the time and it is important to understand the pros and cons to the final decision.

First, let’s understand why the request to disable the WAF for the tester is presented in the first place. The first reaction may be just lazy testing, but that is not the reason. One of the goals of testing an application is to test the application, not a component in front of it. While the WAF is there to stop these types of attacks, it also prohibits understanding the security stance of the application itself.

Getting direct access to the application helps build a better picture of the security of the application. For example, if your WAF is blocking common vulnerabilities (which is good, that is what it is supposed to do) you may not ever realize that you are suffering from insecure coding practices. This may be apparent if other vulnerabilities are identified, however you can’t understand the depth at which the insecure practices are being executed.

Second, WAFs have been victim to bypasses many times in the past. So testing through the WAF may block many attempts of attack, but that doesn’t mean that the vulnerability doesn’t exist. WAF bypass attempts can be a drain on your assessors time and may also then limit the rest of the testing that can be performed in the limited timeframe. Even if the assessor can do an in-depth bypass test, it doesn’t mean a bypass won’t be discovered in the product at a later time.

Finally, what happens if your WAF gets disabled, or misconfigured? This is always a risk with any device. An issue arises and for troubleshooting you put the WAF back in passive mode. You push a rule change that doesn’t work as expected, leaving attack opportunities open. These issues could arise and the application becomes more vulnerable. Unfortunately, you may not even know how vulnerable because the issues were not identified during a test.

When we perform assessments with WAFs in place, we recommend to our clients to allow us direct access to the application for the first portion of the test. This can be doing by white listing our IP address. This is better than disabling the WAF altogether, if possible. We don’t want to open the application up to attack by others during our assessment. Allowing direct access allows us to test the application, not the WAF, to identify vulnerabilities. This gives a more accurate picture of the risk of the application and secure development practices.

The second part of the test will go through the WAF. This allows us to verify if specific vulnerabilities that were found in the application are being effectively blocked by the WAF. This allows a better understanding of the effectiveness of the WAF. You would want to know if the WAF was easily bypassed and a rule change may be needed.

Determining whether or not to allow direct access or not during a test is not always easy. As a tester, you may not always get the direct access. As a client, you may not always want to grant the access. A lot of this depends on your goals of the test. Having an understanding of why direct access is requested helps clients better understand what they are getting out of that assessment.

If you are getting ready to have a penetration test and have implemented a WAF, make sure you have given this topic some thought before the kick-off. Be prepared to provide a response with an understandable explanation for your decision.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.