WAF is a curse

Published on Saturday, 21 February 2015 in Security ; tagged with security, waf, xss, html5 ; text version

Until I write something about the OWASP Winter Code Sprint I did last semester, I want to share a quick thought here:

WAF won't protect you if your application is vulnerable, it is solely a bonus!

WAF?

A Web Application Firewall protects your applications by monitoring the traffic and dropping the obvious attacks before they reach their targets.

For instance, it is known to be useful against automated attacks or well-known JavaScript injections. Even more, it becomes handy when deploying a virtual patch very fast for vulnerabilities like Shellshock for instance.

But it is not a standalone solution at all! You still need to assert the security of your application first!

Lame

If your application does nothing regarding the security aspect, you are assuming that the WAF will never fail. That is absurd of course since you can see new kind of data injections popping almost every weeks on the Internet. Your WAF won't detect them until its rules are updated or until it is smart enough to derive new rules by itself when watching the traffic.

Another aspect to consider is the overhead. You could configure your WAF to monitor everything for every URLs but that will require an important overhead so most of the time, it tries to be smart when analyzing the payloads.

Why am I stating the obvious about WAFs? Well because I saw that specific case not long time ago!

Someone asked to have her web application be pen-tested. During the assessment, I was almost 100% sure that there was an XSS injection but because of the WAF she was using, I couldn't have a proper JavaScript injection and it made me a little bit sad.

We asked her if it was possible to deactivate the WAF just for the gig. It was obvious that our objective was to test the application, not the WAF! She answered, with nice words and a small touch of politic, to go fuck ourselves :/

Won't save you

First I tried to use some basic payloads such as "><script>alert(1)</script> or " onmouseover="alert(1) but each time I had 404 errors because the WAF was blocking the requests. That was frustrating mostly because if I could have had a working payload, it would have meant that I had found a XSS in each and every pages of the application (which sounded really nice to me).

Then I spoke with my comrade to seek his help because XSS isn't my specialty (What is it by the way? Still have no idea). He told me that WAFs, in general, were mostly aimed at JavaScript rather than HTML5. Then he sent me a nice resource which gathers a bunch of HTML5-specific XSS payloads.

Guess what? Using almost the first payload listed there gave me a fully working XSS.

Indeed, using "><input onfocus=alert(1) autofocus> was not detected by her WAF. Nice bonus, the payload does not require any user interaction.

From the behavior I saw, it seems that the WAF was running deeper tests on the parameters but not the whole URL. It seems smart (think overhead) because how could some junks in the URL affect your application if they are not in parameters?

Well, it tried to be smart but it failed really hard here!

Conclusion

When asking for a pen-test on your brandy new application, please deactivate your WAF, otherwise the assessment report cannot be trusted because the WAF obfuscates the root problems...


contactdepier.re License WTFPL2