What is Universal Cross-site Scripting (UXSS)?
Common cross-site scripting (XSS) attacks target websites or web applications that are vulnerable to XSS, because of inadequate development of client-side or server-side code. These attacks have the vulnerable web page as main prerequisite, and their effect is always revolving around the user session on the vulnerable web page itself. In other words, if a user had to browse to a website vulnerable to XSS while having a web-based CRM application open, the attacker will only gain access to the compromised session and cannot gain access to the CRM’s session. This behavior is a result of security functionality implemented in browsers. UXSS preserves the basic XSS traits: exploit a vulnerability, execute malicious code, however there is a major difference:
Unlike the common XSS attacks, UXSS is a type of attack that exploits client-side vulnerabilities in the browser or browser extensions in order to generate an XSS condition, and execute malicious code. When such vulnerabilities are found and exploited, the behavior of the browser is affected and its security features may be bypassed or disabled.
Impact
The net effect of this is the fact that the attacker doesn’t just get access to a compromised session on a vulnerable web page, but may get access to any session belonging to web pages currently opened (or cached) by the browser at the time the attack is triggered.
Simply put, UXSS does not need a vulnerable web page in order to trigger, and can penetrate web sessions belonging to secure, well written web pages, thus creating a vulnerability where there isn’t one.
Web browsers are one of the most popular applications being used, and their development is fast. Providers of web browsers are in a popularity contest, and in order to be on top, they need to implement numerous features over short periods of time. While security features are regarded as important by most of the providers, usability and integration features are usually the hottest (easier to test, easier to implement) and consequently, they have higher priority. Since testing security features requires a significant amount of skill and numerous resources, some of the major providers have bounty programs meant to motivate the community to help improve the security of their browsers. Nevertheless, when a new vulnerability comes into play, the person or group discovering this vulnerability has the opportunity to either exploit it, thus enjoying long-term benefits of repeatedly exploiting such vulnerabilities; or report it and enjoy less benefits (if any). To an extent, it may be a long while until new vulnerabilities are handled, and patches are delivered to end-users.
Moreover, it is not just the browser itself which may have an exploitable flaw, but also any of its many extensions. Most application vendors targeting consumers build browser extensions in an effort to improve the user experience and take advantage of the most popular activity ever: web browsing. The sheer number of browser extensions, available for each browser type, make it impossible to assess their quality in terms of security and their likelihood to contain an exploitable flaw.
The fact that the nature of the attack does not require a vulnerable web page to be exploited, while simultaneously retaining the possibility of gaining access to non-vulnerable web pages, makes UXSS one of the most dangerous and damaging types of attacks from the XSS spectrum. This is further enforced by the fact that UXSS also targets vulnerable browser add-ons or plugins and not just the browser itself.
Well-known vulnerabilities exploitable by UXSS
1. Vulnerability in the Adobe Acrobat extension for Internet Explorer 6 (or Mozilla plugin):
This is an old vulnerability, however, it is a good example of what can go wrong when using extensions that enable code to be executed. The bug in the PDF reader enabled attackers to execute scripts on the client side. This was accomplished by embedding the scripts into malicious URLs (similar to other XSS attacks) and leveraging the extension to run code when a PDF file was opened.
Stefano Di Paola and Giorgio Fedon were the first to document and describe UXSS in the context of an exploitable flaw in the Adobe Reader add-on for Mozilla Firefox. The Adobe plugin was able to populate document forms with data from external sources via a series of parameters which were not properly implemented, allowing an XSS condition to take place. Their original paper can be read here [PDF}.
2. Flaw in the XSS filters of Internet Explorer 8:
David Lindsay & Eduardo Vela Nava have presented this vulnerability in the context of UXSS at BlackHat Europe in 2010. Internet Explorer 8 came with built-in XSS filters which would detect reflected XSS conditions and take corrective action: alter the response before rendering the page. In this particular case, the equal sign was removed by the filter but with a crafted XSS string in place, this logic would cause the browser to create the XSS condition. Microsoft reacted by changing the characters that XSS filters remove. You can find the complete presentation here [PDF].
3. Flash Player UXSS Vulnerability – CVE-2011-2107:
A flaw in the Flash Player plugin in 2011 (all versions, at that time) enabled attackers to get access to Gmail settings and add a forwarding address, using a crafted .swf file. Consequently the attackers would have had access to copies of all emails received by a compromised Gmail account. Adobe has acknowledged the vulnerability in the security bulletin here.
4. Vulnerability in Chrome for Android:
Mobile devices are no exception, and can become the targets of XSS attacks. A vulnerability in Chrome for Android allowed attackers to inject malicious code into arbitrary web pages loaded in Chrome via an Intent object. You can find the Chromium bug report (including sample code) here.
Defending against UXSS
The rule of thumb when discussing defending against UXSS is have everything patched and up to date. This will ensure that the browser version used in your environment, together with the extensions you need, are unlikely to present vulnerabilities exploitable by UXSS. However, does this mean you are off the hook? No. There is no complete assurance that running latest versions will keep you safe; there is a time gap between when a vulnerability is found, published, acknowledged, fixed and a patch is rolled out. During this time frame, you may be vulnerable to UXSS attacks.
Other ways to defend against UXSS depend on the specifics of the vulnerabilities that enable the attack to take place. However, by the time this information is available, a patch that fixes the flaw should be available as well and installing it is usually easier.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
