What’s Wrong with WAFs and How to Hack Them - Part 2

Tuesday, February 07, 2012

Gary McCully


Questioning PCI DSS 6.6... A Web Application Firewall Does Not Equal Security

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)

One example of this can be found when the web application takes user supplied data and inserts it directly into existing JavaScript or HTML tags that the web application uses.  For example, suppose that a web application accepts one parameter named "name1".

For simplicity’s sake, assume that this parameter is passed in a URL like the following: h t t p : / / t e s t s i t e . c o m ? n a m e 1 = B o b.  This parameter is then taken and inserted into the following piece of JavaScript that loads in the user's browser:

< s c r i p t >
v a r   n a m e = ' B o b ' ;
d o c u m e n t . w r i t e ( ' H e l l o   ' +   n a m e ) ;
 < / s c r i p t >

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:

< s c r i p t >
v a r   n a m e = ' B o b ' ;   a l e r t ( ' x s s ' ) ; ' ' ;
d o c u m e n t . w r i t e ( ' H e l l o   ' +   n a m e ) ;
< / s c r i p t >

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:

< s c r i p t >
v a r   N a m e 2 P o s = d o c u m e n t . U R L . i n d e x O f ( " n a m e 2 = " ) + 6 ;
d o c u m e v n t . w r i t e ( d o c u m e n t . U R L . s u b s t r i n g ( N a m e 2 P o s , d o c u m e n t . U R L . l e n g t h ) ) ;
< / s c r i p t >

Suppose that I place this script in an aspx page on an IIS Server.  If I send a URL that looks like h t t p : / / t e s t s i t e . c o m / X S S / R e f l e c t T e s t . a s p x ? n a m e 2 = < s c r i p t > a l e r t ( ' x s s ' ) < / s c r i p t > 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:

h t t p : / / t e s t s i t e . c o m / X S S / R e f l e c t T e s t . a s p x ? n a \ m e 2 = # < s c r i p t >  a l e r t ( ' x s s ' ) < / s c r i p t >

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:

& l t ; s c r i p t & g t ; a l e r t ( & # 3 9 ; x s s & # 3 9 ; ) & l t ; / s c r i p t & g t ;

This string was then reflected back to the user as:

< s c r i p t > a l e r t ( ' x s s ' ) < / s c r i p t >

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 solid Software 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.

Cross-posted from SecureState

Possibly Related Articles:
Information Security
XSS Application Security Vulnerabilities HTML Penetration Testing Web Application Firewalls Attacks Exploits Secure Coding Cross Site Scripting hackers Malicious Code Scripting Gary McCully WAF
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.