What makes an Android application vulnerable to Cross-site scripting (XSS)?

Question

Definition of XSS

If you search the web, there are many different ways to define a cross site scripting attack. Simply put, XSS vulnerabilities occur when a malicious attacker is permitted to inject a client-side script into a web site that is viewed by other people who become the victims of the attack.

An example of an XSS bug within Android O.S

Vulnerability Details

By sending a crafted intent to Chrome for Android, malicious Android apps can inject JavaScript: URIs into arbitrary Web pages loaded in Chrome. Injected JavaScript works in the context of the target Web page's domain, not a blank domain. So it can be used for Cookie theft or so. Such kind of vulnerabilities is often called Cross-Application Scripting.

Version

Chrome Version: Chrome for Android v18.0.1025123 Operating System: confirmed on Android 4.0.4 (Samsung Galaxy Nexus)

Reproduction Case

A sample code of a malicious Android app is attached.

Note

This issue was initially reported to [email protected] on Jul. 7 2012, but recently I heard from Google security team that the issue might not be filed in Chromium bug database. So now I re-submit the issue here which should be a legitimate place for reporting Chrome bugs.

My Question

Although I understand what Cross-Site-Scripting is and how Cross-Site-Scripting can take place. I don't know what factors makes a selection of Android code vulnerable to such an attack.

Answer 1

The specific example is not Cross Site Scripting, it is Cross App Scripting. With a specially crafted intent, an Android app could force another app (Chrome in this example) to execute some script in its (Chrome's) context.

This could abuse some privacy and authentication mechanisms. If I am not missing something, this vulnerability (fixed in Chrome quite a while ago) allowed a malicious app to hijack an opened web session with the user's bank and approve money transfer.

This is a bit of exaggeration, normal banking Web sites are protected from such attacks: they require user confirmation (i.e. re-enter password) to complete any sensitive operation.

The problem with Chrome was that it allowed a 3rd party app to impersonate itself via intent extra, and did not perform enough validation. This was not a security hole in the Android OS, and not an exploit that could be statistically used against random apps on your device, to find one that was not protected.

Answer 2

In most cases, it's due to poor implementation of webview. For an instance, setJavaScriptEnabled(true) method on the WebSettings for a WebView shall trigger to a cross site scripting. It depends on the logic tier if the input is being stored & hence persistent XSS or it reflects.

Webview older than 4.2 when you Enable javascript for it shall always remain vulnerable to XSS unless the developer adds the JavascriptInterface annotation to any method that the developer wants available to the JavaScript. For applications running Android 4.2 - all public methods that are annotated with JavascriptInterface can be accessed from JavaScript.

Other variants of Webview might be something like this:

this.webView.loadUrl("javascript:setContent(" + JSONObject.quote(this.content) + "," + i + ")");

As you can see, the code used the same method (webView.loadUrl) for sending data to the HTML-part of the application. This too triggers XSS. Webview is mostly responsible for XSS on Android.

Answer 3

You are correct that in general, a XSS attack is more a server level attack. Someone fills in a form or posts data to a server, the server accepts that data and fails to sanitise it. The data is tored, potentially with embedded javascript or redirects or links to remote objects with malicious payloads. Someone else visits the site and retrieves the data which as bee posted and the browser interprets the literal data, running the javascript, retrieving the linked object with malicious payload etc.

So, how does this apply to android when your android is usually not a server? In general it can be an issue because many apps use the same technology to render the content - essentially, html, javascript etc. So, if you have a message app and it just accepts an incoming message without doing any sanitising of the data, any javascript or links to embeded objects with malicious payloads will be processed just like in a browser, essentially a XSS attack.