What’s Wrong with WAFs and How to Hack Them – Part 2
In my last blog I spoke about how some organizations use Web Application Firewalls in an attempt to block Cross Site Scripting (XSS) attacks by blocking specific keywords like “script” and “alert”. Unfortunately, in many cases this is not enough to prevent successful XSS exploitation. In attempts to prevent XSS attacks I have encountered many organizations that block or HTML encode specific special characters (<, >, “). In order to be fair I will admit that this prevents many successful XSS attacks, but at the end of the day many of these web applications are still vulnerable to XSS.
Insecurely Passing User Supplied Data (Please pass the jelly…or data)
document.write(‘Hello ‘+ name);
Once the page is loaded, the user is greeted with a pop-up that says “Hello Bob”. Now suppose instead of passing the value Bob, the value Bob’; alert(‘xss’);’ is used. In this case the page that is loaded contains a script that looks like this:
var name=’Bob’; alert(‘xss’);”;
document.write(‘Hello ‘+ name);
Notice how an attacker can successfully exploit this XSS vulnerability without using a <, >, or “?
Document Object Model Based XSS (I am a Professional Model. I can sit for hours without moving a muscle)
Another example of Cross Site Scripting that in many cases bypasses Web Application Firewall filters is Document Object Model (DOM) based XSS. The following script uses DOM in order to obtain a parameter from the URL, and then reflects this parameter back to the user:
Suppose that I place this script in an aspx page on an IIS Server. If I send a URL that looks like http://testsite.com/XSS/ReflectTest.aspx?name2=<script>alert(‘xss’)</script> to the web application I get the following error:
Now if I send the URL to the server with a URI fragment like the following http://testsite.com/XSS/ReflectTest.aspx?name2=#<script>alert(‘xss’)</script> then the script after the pound sign is never sent to the web server. As a result, the attacker controlled script is executed:
Bypass XSS Filters by Encoding Data (I invoke the right of parlay! According to the Code of the Brethren…Wait Wrong Code)
Another example of a way to bypass Web Application Firewall character specific restrictions is to use certain kinds of encoding such as Unicode, US-ASCII, or HTML. For example, once I performed a Black Box Web Application Security Assessment on a web application that accepted HTML encoded data and stored it in a backend database. When a query was made to the database to retrieve the HTML encoded data, the web application reflected the data back as valid HTML. The web application was configured to block the special characters <, >, and “, but the web application firewall gladly accepted the string <script>alert('xss')</script> . This string was then reflected back to the user as <script>alert(‘xss’)</script>.
Conclusion (And they all lived happily ever after…until they passed away)
In summary, just because a firewall is configured to block specific special characters, specific words, and specific character sequences, does not mean that the web application is safe from attack. In the case of Cross Site Scripting, a combination of White Listing, Web Application Developer Training, and a solidSoftware Development Lifecycle (SDLC) with security built in to every phase is needed in order to truly eliminate Cross Site Scripting vulnerabilities. Correctly configured Web Application Firewalls should be used in the context of defense in depth and not as the primary means of protecting the web application.
As a small disclaimer, XSS is just one small vulnerability in a much larger universe of web application vulnerabilities. In order to really start to understand the universe of web application vulnerabilities I would suggest looking through the OWASP Testing Guide. At the time of the writing of this blog, the guide is at version 3.