IE and Edge both uses a default XSS filter which is not powerful like the XSSAuditor(Webkit/Blink).
This is how the XSS filter is implemented.
https://msdnshared.blob.core.windows.net/media/TNBlogsFS/BlogFileStorage/blogs_technet/swi/WindowsLiveWriter/IE8XSSFilterArchitectureImplementation_7E69/pic1_thumb.png
(source: https://blogs.technet.microsoft.com/srd/2008/08/19/ie-8-xss-filter-architecture-implementation/)
Here’s a more detailed image.
(source: http://www.adambarth.com/papers/2010/bates-barth-jackson.pdf)
In some websites urldecode() is being performed in the backend. Let’s imagine we have a PHP code snippet like this in the back end.
[code language=”php”]
[/code]
In these kinds of situations I found out that it’s easy bypass the XSS filter by performing double encoding to the filtered character or any valid character in the regex. Once our application decodes one level the XSS filter won’t find anything harmful in the encoded payload and the regex rules won’t apply.
The regular expressions or the filter rules can be found inside the “mshtml.dll” DLL. Let’s look at a few.
[code language=”javascript”]
{[ /+\t\”\’`]{o}n\c\c\c+?[ +\t]*?=.}
[/code]
In the above filter rule {o} will be filtered with the “#” neuter replacement character.
[code language=”html”]
[/code]
If we double encode the character “o” no longer the filter will apply.
[code language=”html”]
[/code]
You can see in the source our payload with no neuter replacements.
In Edge too this will apply decoding is being done in the back end server.
In Edge instead of () we can use “.
[code language=”html”]
[/code]
I have tested on the following versions.
Internet Explorer
Version : 11.0.9600.18378
Edge
Version: 20.10240.16384.0
Mentions
https://www.webarxsecurity.com/bypassing-modern-web-application-firewall
hmm nice one 🙂 mshtml.dll ?
Thanks bro 🙂
Have you report to Microsoft Security Team?
Yes, they said they no longer take reports of XSS bypasses.