Mutation XSS- A Unique class of XSS
By Pankaj Rane - May 29, 2019
Today We’ll talk about the lesser known derivative of XSS called Mutation XSS (mXSS). Readers who are not aware of the Cross-Site Scripting attack, I’ll briefly explain what is XSS and it's types.
Cross-Site Scripting or XSS is one of the most common injection vulnerability that exist in modern as well as legacy Web Applications. It is a code injection attack where the attacker injects malicious code into web pages which are viewed by other users. It occurs when the user input is not properly validated. XSS effects differ in a scope from a petty nuisance to momentous security risk, based on the sensitivity of the data handled by the target site.
Cross-Site Scripting attacks have traditionally been organised into 3 types.
1. Stored XSS or Persistent XSS
2. Reflected XSS or Non-persistent XSS
3. DOM based XSS
THE RISE OF mXSS
Back in 2007, Yosuke Hasegawa discovered a Cross-Site Scripting vector based on the mistreatment of the back-tick(`) character in a single browser implementation. Initially it looked like an implementation error that could be easily be fixed but it was the birth of new class of XSS vectors "Mutation XSS" which was coined by Dr.Mario Heiderich, security researcher from Berlin.
As per OWASP,
"Mutated XSS happens when the attacker injects something that is seemingly safe, but rewritten and modified by the browser, while parsing the markup. This makes it extremely hard to detect or sanitize within the application logic."
The main root cause mXSS to occur is due to innerHTML. This vulnerability affects browsers like IE, Chrome, Firefox etc. High-profile applications like Yahoo, OpenExchange, Rediff Mail etc and several commercial products were vulnerable to mXSS.
The big deal about this attack is that it manages to bypass widely deployed server side XSS protections techniques like HTML purifier, Kses, htmlLawed etc. and client side filters like XSS auditor, IE XSS filter, WAF systems, IDS and IPS.
The mXSS happens when HTML mutates from a safe form into an unsafe form. Usually when innerHTML is read and written. This technique fools the HTML parser to rewrite the code.
The below example of mXSS was discovered by Mario where the listing element mutated its content to execute XSS:
If you observe there is no malicious content in the script as this code will not execute due to HTML encoding. Now, place this piece of code into another code using inneHTML property.
When this code will run, browser will read innerHTML and call document.getElementById(‘x’).
The expected result of the alert would be-
however IE8, IE9 and IE10 browser decodes the entities and returnsinstead. The XSS vector mutated from a safe state to an unexpected unsafe state.
The 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.
MUTATION XSS IN GOOGLE SEARCH
Recently in Feb 2019, mXSS was discovered by a security researcher Masato Kinugawa.
This vulnerability was in the open-source Closure library (proprietary of google and used in Google Search).
On September 26, 2018 one of the developers who was working on Closure library facing issues with user interface design so he created a commit which caused to remove the part of input sanitization. However, Closure library was using DOMPurify (https://github.com/cure53/DOMPurify) which sanitizes HTML and prevent XSS attacks but it was not effective due to removal of code commit in September 2018 which opens up an opportunity for the researcher in executing mXSS in Google Search.
Check the below video PoC it explains how mutation XSS works, and how Client-side Sanitization can be implemented.https://www.youtube.com/watch?v=lG7U3fuNw3A