Same-origin policy for file: URLs in Android browser?

Question

When you load a file:// URL in an Android WebView or in the Android browser, what does it treat as the origin? What can the Javascript on that page access? Can it access other files in the same directory? Other files elsewhere on the device?

Background: I know that, in desktop browsers, the same-origin policy for file:// URLs has varied over time and from browser to browser. For instance, some browsers used to treat all file:// URLs as being within the same origin, so any one page could script all pages with the file protocol. Today, I think some desktop browsers use the directory as the origin (e.g., file://a/b/c.html is in the same origin as file://a/b/d.html and they can script each other, but they are in a different origin from file://a/y/z.html and cannot script it), while I think other browsers use the entire path as the origin (i.e., file://a/b/c.html is in a different origin from file://a/b/d.html and cannot script it or any other file URL). What's the situation for the Android browser / the renderer used by Android WebViews?

Answer 1

When you execute a .html file using the file:// URI that script is run in the "file" zone. Which means that you can read files on the local file system using an XHR. (This is subject to change, and is also easy to verify)

As with most "standards" it depends on what browser you are using. If you are using Firefox on any system, including android, JavaScript can only access files in its own directory and all sub directories. But this is a recent change FireFox's SOP (May 1st 2012).

WebKit is a different story. If you have a script running in the file:// zone then you can read any file on the local file system, so long as the browser is running as a user with the necessary file permissions (/etc/passwd should always be world readable).

It should be noted that most browsers will not allow you to redirect from a web zone (http, https) to the file zone. Once upon a time you could do this, but it was a feature that was ripe for abuse. So if there was a DOM based XSS vulnerability in a local .html file it would be difficult exploit (I am not aware of a method of doing this, and this method would likely be a vulnerability). Although this theoretical vulnerability maybe "cross-zone scripting" which would allow an attacker to exfiltrate files off of the local file system, it would be very difficult to exploit due to redirection restrictions.