Bypassing Web application Firewall — Part 5

Update: This article is part of a series. Check out the full series: Part 1, Part 2, Part 3, Part 4, Part 5!

DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on differ- ent domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was placed in the re- sponse page, so you can see the difference, and why we are examining this type too.

Also, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques, like the WAFs that we are examining, impotent to such attacks, and this is why this attack is important to us. Let’s examine the following code, from an e-shop that supports many currencies:

which executes the same script, but with the addition that the script is not being sent to the server, so we have suc- cessfully bypassed a WAF of any type of server side control. In this attack, the server will only see the URL, until the page.html point.

Now, you can see that the attack is more or less the same, but we are exploiting a different aspect of the client side, and in this situation, if the victim has an outdated Acrobat Reader installed, the script will be executed without going to the server. As we can understand, DOM-based XSS is really dangerous and no WAF can filter it, due to its nature.

Bypassing Blacklists with JavaScript

There are countless ways that we can create a JavaScript to bypass this type of protec tion, but let’s

now talk about the three different approaches that we can use to bypass blacklists.

BruteForce: With this method, we are trying many payloads and we expect some of these to execute. This isthemethodthatmostofthetoolsthatwetalkedabout,andwilltalkabout,areusing,anditmaybeagoodmethodforsometypeoffilters,butaswesaidmanytimes,thesemethodsfailbecauseautomatedtoolscan- not understand the context, and every attack’s context varies in each occasion.

* BrowserBugs: AswesaidintheAdobeAcrobatXSSexample,therearesomewaystobypassaWAFbyex- ploitingabuginthetarget’s browser.Thisisthelastapproachthatsomeonewilluse,becausewehavetosearchforolderbrowserswithsecurityissues,addonsthathavesecurityissues,orevenzerodays,tobeableto exploit them and bypass the limitations that the WAF has added.

REG-EXreversing: Thebestapproachinblacklistbypassingisthereg-exreversing.Aswehavealreadysaid,WAFsrelyonmatchingthepayloadswesentwiththesignaturestheyhavestoredinthedatabase,andthesesignaturesareintheformofcomplexregularexpressions.Ifthepayloadmatchesanyofthesesignatures(reg-ex)theWAFtriggersup,andasyoucanunderstand,theWAFdoesn’ttriggerupifnosignature matchesourpayload.Inthismethod,wetrytoreversetheseWAFsignatures,andonceweknowtheblack- list of the WAF, we can produce scripts and attacks that can bypass all the filters and not trigger up the WAF. First of all, we have to try and insert harmless tags like to see if they are blocked from the WAF and see how they get rendered from it in the HTTP response. We check the following:

succeed. So, for this example we are supplying something like this:

After all these checks, let’s supply an tag and examine its response, and if the WAF is making the same checks, like it did in the first step we saw, and if not, we try to insert a JavaScript statement inside the hreftag.

Now we have to check the response of this alteration, and if the WAF has filtered out the JavaScript statement in the <a> tag or only stripped the JavaScript, and if yes, we try to bypass this filter by playing with the case of the let- ters, like we did earlier. If only the JavaScript keyword is filtered out, there are plenty of ways that we can bypass this filter by encoding it.

To continue, we have to try an event handler to execute JavaScript,

If we are now able to inject this event, it means that the WAF is only filtering a bunch of events and not all of them. With HTML5, we have more than 150 event handlers that we can use JavaScript with, and there is a big change of not filtering out all of them by the WAF. One of the less commonly filtered out event handlers is the “ onhash- change” and it can be used as follows:

This was one of the approaches that someone can follow to bypass a WAF, but not the only one.

There are more ways to test it that are due to the liking and experience of the pentester and the

situations that he is handling.

To conclude this section let’s examine some situations, where we use some other commonly used tags that we can use to inject JavaScript as we did earlier. Let’s start with some tags that contain the src attribute. There are many tags that use this attribute and we can test them in the following way:

As you can see here, we can add event handlers in the tags that use src attributes and we can use it by separating the tag from the src with a . With this way we can many times trick the WAF and bypass it. Two other interesting tags that use the src attribute are the iframe and the embedded, and to try and bypass a WAF, we can use them as follows:

You can see that we can implement a JavaScript many more ways than we can think. In the first one, we take off the space between the iframe and src, so the WAF cannot identify them as keywords. In the second one, we see that we use again the / for separation and we then use base64 to encode the event handler. If decoded, it produces . Other attributes of some tags that we can use are the poster and the data, that can be many times used to bypass a WAF, as they tend not to block it as malicious. For example:

You can see that we have used them more or less the same way as with earlier scripts, which tells us that we can have many alternative ways to try and bypass a WAF. Now, an attribute that is proven not to be filtered by many WAFs is the formaction attribute, due to its rare use. We can use it as follows:

WAFNinja is a Python written script, which is one of the best tools for automated bypassing WAF. WAFNinja comes with a variety of payloads and fuzzing strings, which are stored in a local database file that comes with the tool. It is also created this way to be easily expandable and simple to use. Also, it supports HTTP connections, with both GET and POST requests and the use of cookies in order to access the pages that need authorization. Finally, we have the choice to set up an intercepting proxy, but we will not examine that in this chapter. We can simply download and run WAFNinja on our Linux machine by executing the following:

git clone

And from now on,inside the folder ofWAFNinja, we can runit by executing The logic of WAFNinja execution goes like this: [-h] [-v] {fuzz, bypass, insert-fuzz, insert-bypass, set-db} …

And we can use the following functions:

python fuzz -u “" -c “phpsessid-

python bypass -u “" -p “Name=PA- YLOAD&amp;Submit=Submit” -c “phpsessid=cookie” -t xss -o output.html

To do so, we are going to use tamper scripts that alter the payloads sent to the server automatically. In some cases, we might need to combine a few tamper scripts together in order to fool the WAF, and we can find a full list of them here: . Let’s examine two scripts that will target MySQL data- bases. These scripts will convert all spaces to block comments with random text. To start SQLmap in Kali Linux, we

The extended version of tamper script we used here, the, will also add the com- ments in between certain function names and the parenthesis. Also, the options we used are:

Now that we executed SQLmap, the tamper script has replaced the spaces with the %23randomText%0A , which as we can see is URL encoded. The functions andCONCAT() that we examined in module 2, got changed toFUNCTION%23randomText%0A() , because in our example it is identified that they were blocked by

To continue, two other interesting tamper scripts that we can use and help automate the encoding processes are the and These are really useful scripts for bypass, when the WAF is filtering out keywords. They can find the best way out, and we can simply use them again with the -tamper option. An exam- -u “http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" — cook- ie=”security=low; PHPSESSID=bb61j7e8jrsfd87s9037fsdgf3" -D dvwa -tables -tamper “”

We use the second script,, if the application decodes the URL with the request. The simple, is the simple one that helps us with encoding. Additionally, if the application is programmed in ASP/ASP.NET, the and scripts can be used to hide the true payload. An inter- esting characteristic of ASP is the ability to add as many percentage signs as we want in between characters, so the following, AND 1=%%%%%%%%1 , that we can see in image 3, is completely valid.

There are many tamper scripts in SQLmap that have their own use, so you have to see what exists and use the proper script in each case. It is a really useful feature that can be used easily and with good results.

Bypassing WAF Practical Examples

Until now, we have talked more about theory (not that this is bad) but we have seen only a small amount of real at- tacks in WAFs, so now let’s examine some true attacks on WAFs that are widely used, and are based on true vulner- abilities found on them.

Keep in mind that these vulnerabilities have been patched and will work only on outdated WAFs, we

cannot supply ways of bypassing a real WAF without informing the owner.

Incapsula WAF provides solutions to protect websites against SQL Injections, cross site scripting, illegal resource ac- cess, OWASP top ten threats, and web 2.0 threats including comment spam, fake registrations, site scraping and ma- licious bots. It works by changing a website’s Domain Name System (DNS) to route the website traffic through Incap- sula. Incapsula then filters out malicious attacks from bots and website scrapers.

As we said in Module 1, one of the most used ways to bypass WAFs is the HTTP parameter pollution and HTTP pa- rameter fragmentation. So let’s take the following example website that is protected byIncapsula:

Now, the page sees the a parameter as As you can understand, this can be eas- ily filtered out by a WAF, and Incapsula handles these attacks by combining all the parameters with the same name like the ASP does, before passing it to the later stages. In this security measure, a vulnerability has been found that allows the stage of normalization of the parameters to create end results different than ASP does. So, if we say that the attack link we provided earlier can be blocked by Incapsula, the following can bypass it:

As you can see, after the parameter name there is a null byte. Incapsula treats parameters followed by a null byte differently from another parameter with the same character. So, a and a for Incapsula is a different parameter. As a result, when combining the parameter with the same name, it will not see a malicious string and it will not filter it out.

Now, let’s continue with some XSS attacks in the same WAF. This WAF is filtering correctly the common XSS strings that we used without any encoding, like the <script>alert(document.cookie)</script> . Also, trying to im- plement an event handler in a simple HTML tag, is proven useless too, because it is filtered out too. So, something like will be filtered out, but to our surprise, something like this<img src=x onerror=”input”> is not detected. So the aspect that is blocked is the JavaScript inside the event han- dler and not the event handler alone.

The first way that has been found to bypass this measure, is to use a mix of HTML, double-URL and Unicode encod- ing. So, you can see that we had to dig deep to find a bypass in this WAF and make many tests, but in the end there is always a way. Let’s now provide the following:

Now, this is the earlier payload but with some alterations. Also, this payload was encoded first by HTML and then by double-URL encoding. Double-URL encoding works on specific servers that URL-decode the client’s input multiple times.

The second XSS bypass, which is publicly available, is based on the JS-F**K, which is a technique that has been intro- duced to create JavaScripts with only 7 characters. So something like the following will do thejob:

With this payload we can do anything we want to the website, without the WAF blocking our actions, but the only obstacle is the length, because most servers restrict the GET request URL length. Nevertheless, the payload is a really good solution and can successfully bypass the Imperva Incapsula WAF.

The WebKnight WAF is an OpenSource WAF for IIS and other web servers, and it is widely used. It is a really good solution, but of course we are here to bypass it, and it has one of the most vulnerable filter rule set of all WAFs, but it is trying to get better. Now two SQL payloads presented by OWASP, that could bypass easily a WebKnight WAF,

As you can see, both of them disclose serious personal information, with username and password included, and the payload isn’t encoded at all. Also, this WAF is vulnerable to a JavaScript event handler, the ontoggle that occurs when the user opens or closes the <details> element, and it is supported on all browsers. For example:

Finally, we have another event handler, the onshow one, that fires when a <menu> element is shown as a context menu, and works only on the Firefox web browser. When a user right clicks, the script will be executed, bypassing WebKnight XSS filter detection, and we can produce it, as follows:

ModSecurity is another open source WAF that is widely used, and takes security seriously, with challenges that any- one can participate, and have as a result the hardening of the WAF. The first vulnerability we are going to see on this WAF is based on the null byte, that we have talked many times in this course. We simply have to use the null byte inside the script tag. This will bypass the WAF and perform the XSS attack without problems. For example:

ModSecurity fixed this issue by applying a filter rule that strips all the null bytes from the input. The next bypass tech- nique is based on the characters that browsers are treating as space characters. Each browser has a different set of these characters which you can see below:

To exploit this, we are using one of these characters between the onevent name attribute (like the onmouseover and ontoggle) and the equal sign character. ntoggle%0B%3D

So here we are watching the which internet explorer is handling as a space character, and executes correctly the payload. As a practical example, we can give:

This is a real bypassing example of an earlier version of ModSecurity WAF. Finally, let’s see a bypassing example that works on environments that escape the user’s request three or more times. An exploit to this approach of ModSecu-

Let’s conclude by saying that most of these techniques we examined with XSS attacks work on SQL Injection attacks as well. So, for example, if we supply the following:

it will bypass the ModSecurity WAF, because it recognizes the on Internet Explorer as a space.

For our last examples on WAF bypass, let’s examine the F5 Big IP, that is one of the most advanced enterpricse level WAFs, but as you will see, even the best fall. The first bypass method has to do with event handlers, the onwheel and onshow, with the second one only working in the Firefox browser. For example:

As you can see here, we have some pretty simple payloads, with no encoding that succeeds in bypassing the F5 Big IP WAF. Another way that we have analyzed and success in bypassing this WAF is with the JS-F**K encoding, For ex- ample, in extension of the previous examples, we have:

As you can understand, inside the brackets we can use a JS-F*ck Payload, for example, if we want to give alert(1), we would give the following:

Finally, the last bypass we are going to see is like our first one with HTML encoding and double URL encoding. With this method, the previous examples will transform to:

Originally published at

Cyber Security Analyst & researcher