Universal Cross-Site Scripting Attack (UXSS)

A classmate asked, with Baidu search under, found that domestic related to the basic is not, write an article to introduce. But see there is a ready-made introduction, take to translate the changes under.
The content of this article is mainly translated from the article, to delete some unnecessary words, do some sorting and modification, and then add some cases.

http://www.acunetix.com/blog/web-security-zone/universal-cross-site-scripting-uxss/

What is UXSS?

We all know that there are reflective XSS, storage-type XSS, DOMXSS, and MXSS, also known as Mutation XSS (article address http://drops.wooyun.org/tips/956), which was translated by Gainover in the Wooyun Knowledge Base.
may be less than the students understand what is UXSS,UXSS full name Universal Cross-site Scripting, translation comes from the general-purpose XSS, also known as Universal XSS.

So, what is the difference between UXSS because of the several XSS mentioned earlier?

Common XSS attacks are targeted sites or applications that have vulnerabilities due to a problem such as a client or server-side code development that is not rigorous. The prerequisites for these attacks are that the pages are vulnerable, and their impact often surrounds the user session of the vulnerability page itself. In other words, because of the security features of the browser, an XSS attack can read only the infected session and cannot read other session information, that is, the impact of the same-origin policy.
UXSS retains the features of basic XSS, exploits, and executes malicious code, but there is one important difference:
Unlike common XSS,UXSS, a type of attack that exploits a browser or browser extension vulnerability to create conditions that produce XSS and execute code.
So many people should understand that, in layman's parlance, we are all targeting the Web application itself, because the Web application itself is a loophole to exploit the attack, and UXSS different from the browser or browser extension vulnerability to "make XSS vulnerability", Then the rest of us can exploit the attack like normal XSS.

Effect
So what is the difference between UXSS and the usual XSS? As we mentioned earlier, because of the same origin policy, even if there is XSS in a vulnerability page, we can access its user session information, etc., but cannot access the related session information of other domains, because UXSS is exploited by the browser itself or the browser extender vulnerability. Therefore, session information can be accessed for all pages opened or cached by the browser when the attack originated, even for different domains. Simply put, UXSS does not need a vulnerability page to trigger an attack, it can penetrate into a security-free page, creating a vulnerability that was originally security-free (such as the following example).
Web browsers are one of the most popular applications that are being used. The browser may have a vulnerability to be found, there is a whole loophole in the process, when a new vulnerability is discovered, whether it is to hide the loopholes in their own use or report to the official, and this process has a period of time, the process of vulnerability can be exploited in UXSS.
Not only is the vulnerability of the browser itself, but now mainstream browsers support the installation of extensions, and many browser extensions can lead to more vulnerabilities and security issues.
Because the UXSS attack does not require a vulnerability in the page itself and may access other security-free pages, it makes UXSS one of the most dangerous and destructive types of attacks in XSS.

UXSS case
1. IE6 or Firefox extension Adobe Acrobat vulnerability
This is a relatively old loophole, but this is a classic example. Causes an error when using the Extender, allowing the code to execute. This is a bug in the PDF reader that allows an attacker to execute scripts on the client. Constructs a malicious page, writes a malicious script, and runs code when a PDF is opened with an extender.
Stefano Di Paola and Giorgio Fedon the first record and description in a bug that can be exploited in a plugin for Adobe Reader in Mozilla Firefox browser UXSS
Adobe plug-ins allow for the filling of document forms from external data sources through a series of parameters, allowing cross-site scripting attacks if not performed correctly. Original pdf:http://events.ccc.de/congress/2006/fahrplan/attachments/1158-subverting_ajax.pdf or see HTTP// Jeremiahgrossman.blogspot.com/2007/01/what-you-need-to-know-about-uxss-in.html

2. IE8 Cross-site script filter defects
David Lindsay and Eduardo Vela Nava have shown the Blackhat use of the loophole in Europe UXSS in 2010.
An XSS filter is built into the IE8 to detect reflection XSS and take corrective action: Change the response content before the page is rendered.
In this particular case, the equals sign will be removed by the filter, but this logic will cause the browser to create XSS conditions through a well-constructed XSS string in a particular place. Microsoft's response is to change the characters that the XSS filter removes. You can view Pdf:http://p42.us/ie8xss/abusing_ie8s_xss_filters.pdf

3. Flash Player UXSS Vulnerability –cve-2011-2107
A flaw in the 2011 Flash Player plug-in (all versions at that time) allowed attackers to access Gmail settings and add forwarding addresses by using the constructed. swf file. As a result, an attacker can receive copies of all messages from any compromised Gmail account (they are sent with a CC copy). Adobe acknowledges the vulnerability, as described in http://www.adobe.com/support/security/bulletins/apsb11-13.html

4, the Android version of Chrome Browser vulnerability
Mobile devices are no exception, and can be a target for XSS attacks. There is a vulnerability in Chrome's version that allows an attacker to inject malicious code into any Web page that chrome has loaded through the intent object. See https://code.google.com/p/chromium/issues/detail?id=144813 for details

Other examples

Http://insert-script.blogspot.com/2013/08/uxss-internet-explorer-euc-jp-parsing.html

Http://www.rapid7.com/db/modules/auxiliary/gather/apple_safari_webarchive_uxss

http://www.wooyun.org/bugs/wooyun-2014-074655

http://www.cnvd.org.cn/flaw/show/CNVD-2012-5462

http://www.wooyun.org/bugs/wooyun-2014-071915

http://cxsecurity.com/issue/WLB-2012100086

Http://www.maths.usyd.edu.au/u/psz/ff-utf7-uxss.html

More people search for themselves to put

Analysis of the code example
Originally finishing this article at the time did not know Daniel issued a UXSS, finished writing on Wooyun just see Mramydnei Daniel issued "Android browser SOP Bypass Vulnerability (UXSS)" Vulnerability (see http://zone.wooyun.org/content/ 14945), it is added to the article.
In a brief analysis, the vulnerability is to construct a page that embeds an IFRAME and then \u0000 the browser's SOP bypass for XSS.
More details can be seen in Daniel's blog and reference articles http://parsec.me/625.html, http://parsec.me/660.html.

Prevention
The rule of thumb to guard against UXSS is to lay out all the patches and keep the latest version.
This will ensure that the version of the browser you are using in your environment and the extensions you need are unlikely to be exploited through UXSS.
But does that mean you have peace of mind? No, running the latest version is not guaranteed to be completely secure. When a vulnerability is discovered, submitted, confirmed, repaired, the patch has been released, there is a time lag between, and during this period, you will likely receive UXSS attacks.

In addition, more XSS-related knowledge can be accessed by https://xssing.org, which is currently added in the data

Universal Cross-Site Scripting Attack (UXSS)