Monthly Archives: September 2016

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 or @jardinesoftware on twitter.

Login Forms and HTTP

Does your application have a login form? Do you deliver it over HTTPS to protect the username and password while being transmitted to the server? If you answered yes to both of those questions, are you sure?

Many years ago, before there was a huge push for HTTPS all the time, it was common practice for many applications to load a login form using HTTP, but then submit the form over HTTPS. This was accomplished by setting the action attribute of the form to the full HTTPS version of the site.

<form action=”” method=”post”>

There was a flaw in this setup. The flaw is not even with the submission of your credentials. Instead, the issue is how that login form is initially loaded. Remember we said that the initial request was HTTP? The belief was that because the loading of the form doesn’t transmit any sensitive data, it would be ok to use HTTP. You could even take a trip back to the performance wars during that time stating that HTTP was much faster to load. (We learned a lot of the years).

The problem is that if there is a malicious user (attacker) on your same network that is able to redirect your traffic through them they could manipulate the initial load of the page. Imagine if the attacker intercepted your request to the login page (initial load) and changed the action of the form to a different site?

<form action=”” method=”post”>

Notice how the new form submission will go to a different site, not even using HTTPS. From the end user’s point of view they wouldn’t even know the form was going to send their credentials to a different site.

Over the years, we have seen the use of this methodology shrinking down. Many sites are now loading their login forms all over HTTPS. As a matter of fact, many sites are 100% HTTPS.

But Wait!!

There is another angle to this that is often overlooked, but works very similar. Does your site allow it to be loaded into frames? I have seen a lot of sites that have been including another application’s login form using either frame sets or frames. The issue, the container site is often a simple marketing or branding site and runs over HTTP.

Like the above example, the HTTP site is including a frame reference to an HTTPS site. Again, the login form submission is still correct. However, it is possible that the attacker from the previous scenario could intercept the containing page and change the reference for the login frame. In this case, the attacker would most likely create a page that is identical to the real login form and point the frame to that one. The user would have no idea that the authentication page was incorrect, because it would look like the original. When the user submits their credentials, they would then be submitted to the malicious user instead of the real site.

It is recommended to not allow your site to be hosted within a sub frame. There are plenty of articles that discuss frame busting techniques and you could look into the X-Frame-Options header as well. If your form doesn’t load in a frame then your risk of being included on a non-secure site is reduced. For all other scenarios, there isn’t a lot of reason to not be using HTTPS from end to end. By securing all of the transactions, it reduces the risk that an attacker can easily manipulate that traffic.