Mutation XSS

Hello Friends,

Welcome back :) Today I'm sharing my research on mutation cross site scripting. On studying and reading lot of stuff finally decided to write article about mXSS. I hope you will find it useful.

Mutation Cross site scripting (mXSS)

The New class of XSS vector, the class of mutation based XSS (mXSS) vector discovered by Mario Heiderich. This mXSS may occur in innerHTML. This vulnerability affects major browsers like IE, Firefox, Chrome etc.

Famous applications like Yahoo, Rediff mails, Zimbra etc like commercial products were vulnerable to mXSS. This type of XSS vectors managed to bypass widely deployed server side XSS protections tecniques like HTML purifier, Kses, htmlLawed etc. and client side filters like XSS auditor, IE XSS filter, WAF systems, IDS and IPS.

Introduction

The mXSS is an XSS vector that is mutated from safe state to unsafe unfiltered state. Server- and client-side XSS filters share the assumption that their HTML output and the browser-rendered HTML content are mostly identical. The most common form of mXSS is from incorrect reads of innerHTML. The user provided content is mutated by the browser, such that a harmless string passes nearly all XSS filters is ultimately transformed into active XSS attack vector by the browser.

As shown in above diagram, Attacker prepares his malicious script in HTML format and injects into web application. Due to server side validation script will get filtered or re-written into encoding mechanism used. Or if client side XSS filter is applied string will be checked again. At this point attacker cannot execute XSS attack.

However, if Attacker injects his HTML malicious script into DOM by using innerHTML property, the browser will mutate the string. The mutated string now contains valid XSS vector, and attack will be executed on rendering of newly created DOM element. Both server and client side filters will fail to capture malicious code as there is no executable code.

If innerHTML is only used to insert trusted code from the web application itself into the DOM, it is not vulnerable.

Description and Attack scenario

In the above section we understood the flaw in innerHTML. In this section we will try to execute mXSS by taking advantage of innerHTML property. Take a look on below string,

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

 If you look it carefully there is no harmful content in the script as this code will not run due to HTML encoding. Now we will put this piece of code into another code using innerHTML property.

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

<script>alert(document.getElementById('x').innerHTML)</script>

 When this code will execute, browser will read innerHTML and call document.getElementById(‘x’).

But our x value is defined as our HTML encoded string which is

&lt;img src=1 onerror=alert(1)&gt;

 Now if we render this page with code the expected result is below string with popup window, 

 “&lt;img src=1 onerror=alert(1)&gt;”

 However browsers like IE8, IE9 decodes the entities and returns
 

“<img src=1 onerror=alert(1)>” instead.

 

 The vector mutated from safe state to unexpected unsafe state. The mXSS works on multiple decoding level. Here it first renders actual HTML and each decoding/read of innerHTML is counted as another mutation since it could be decoding multiple times.

 Let’s do it on Firefox 43 browser we will see below,

But if we try same thing on IE 8 or IE 9, IE will read and write (decode) HTML multiple time and attackers XSS payload will mutate and execute. 

 To show the demonstration we will use below mXSS practice site,

http://www.businessinfo.co.uk/labs/mxss/index.php?ie=8

Mutated payload will execute on click,

 

mXSS - XSS attacks that are only successful because the attack vector is mutated by the browser, as a result of behavioral mishaps introduced by the internal HTML processing of the user agents.

That's all guys I hope this will surely help you. stay tuned for RPO XSS in next post.

*Note: Click on image to view full size images*