Computer scientists have uncovered architectural weaknesses in both the iOS and Android mobile operating systems that make it possible for hackers to steal sensitive user data and login credentials for popular e-mail and storage services.

Both OSes fail to ensure that browser cookies, document files, and other sensitive content from one Internet domain are off-limits to scripts controlled by a second address without explicit permission, according to a just-published academic paper from scientists at Microsoft Research and Indiana University. The so-called same-origin policy is a fundamental security mechanism enforced by desktop browsers, but the protection is woefully missing from many iOS and Android apps. To demonstrate the threat, the researchers devised several hacks that carry out so-called cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks to surreptitiously download user data from handsets.

The most serious of the attacks worked on both iOS and Android devices and required only that an end-user click on a booby-trapped link in the official Google Plus app. Behind the scenes, a script sent instructions that caused a text-editing app known as PlainText to send documents and text input to a Dropbox account controlled by the researchers. The attack worked against other apps, including TopNotes and Nocs.

All your credentials belong to us

The Plaintext app in this demonstration video was not configured to work with Dropbox. But even if the app had been set up to connect to the storage service, the attack could make it connect to the attacker’s account rather than the legitimate account belonging to the user, Wang said. All that was required was for the iPad user to click on the malicious link in the Google Plus app. In the researchers' experiments, Android devices were susceptible to the same attack.

A separate series of attacks were able to retrieve the multi-character security tokens Android apps use to access private accounts on Facebook and Dropbox. Once the credentials are exposed, attackers could use them to download photos, documents, or other sensitive files stored in the online services. The attack, which relied on a malicious app already installed on the handset, exploited the lack of same-origin policy enforcement to bypass Android's "sandbox" security protection. Google developers explicitly designed the mechanism to prevent one app from being able to access browser cookies, contacts, and other sensitive content created by another app unless a user overrides the restriction.

All attacks described in the 12-page paper have been confirmed by Dropbox, Facebook, and the other third-party websites whose apps were tested, Wang said. Most of the vulnerabilities have been fixed, but in many cases the patches were extremely hard to develop and took months to implement. The scientists went on to create a proof-of-concept app they called Morbs that provides OS-level protection across all apps on an Android device. It works by labeling each message with information about its origin and could make it easier for developers to specify and enforce security policies based on the sites where security tokens and other sensitive information originate.

As mentioned earlier, desktop browsers have long steadfastly enforced a same-origin policy that makes it impossible for JavaScript and other code from a domain like evilhacker.com to access cookies or other sensitive content from a site like trustedbank.com. In the world of mobile apps, the central role of the browser—and the gate-keeper service it provided—has largely come undone. It's encouraging to know that the developers of the vulnerable apps took this research so seriously. Facebook awarded the researchers at least $7,000 in bounties (which the researchers donated to charity), and Dropbox offered valuable premium services in exchange for the private vulnerability report. But depending on a patchwork of fixes from each app maker is problematic given the difficulty and time involved in coming up with patches.

A better approach is for Apple and Google developers to implement something like Morbs that works across the board.

"Our research shows that in the absence of such protection, the mobile channels can be easily abused to gain unauthorized access to a user's sensitive resources," the researchers—who besides Wang, included Rui Wang and Shuo Chen of Microsoft and Luyi Xing of Indiana University—wrote. "We found five cross-origin issues in popular [software development kits] and high-profile apps such as Facebook and Dropbox, which can be exploited to steal their users' authentication credentials and other confidential information such as 'text' input. Moreover, without the OS support for origin-based protection, not only is app development shown to be prone to such cross-origin flaws, but the developer may also have trouble fixing the flaws even after they are discovered."

I wonder if they've checked Windows Phone yet? Or the new Blackberry? Granted, those are pretty minor mobile platforms...

It comes down to whether or not same-origin policy is enforced at the API/Sandbox for Windows Phone apps (which, I think, have the same restrictions as "modern" apps). I did a quick search, and didn't see anything obvious in the first couple of pages of hits.

I wonder if they've checked Windows Phone yet? Or the new Blackberry? Granted, those are pretty minor mobile platforms...

*cries*hugs Lumia*

Given that Microsoft Research was involved, I'm sure they checked Windows Phone. You could then read its non-mention to mean they are hiding it, or that it isn't vulnerable.

True. I'd rather not be cynical about it (which has gotten tiring over the years), but I'd really, really prefer something spelled out.

Im semi-expecting at least one WP site to claim "immune!", and fanbou off why WP is going to rule everything with the next WP phone that comes out. Which, really, is why I don't go to that one specific site anymore. Hope one of the better ones asks into the matter.

I find it really surprising that Google didn't enforce same-origin restrictions on cookie-like data in Android. If anyone should understand basic web security, I'd expect it to be google.

Me too. All of our experience is mobile webkit is even more strict than desktop webkit when it comes to XSS.

The article is confusing though, the only attack it actually demostrates has nothing to do with browsers or cookies and isn't a system bug at all. It just looks like PlainText is allowing any app to link it to dropbox, instead of only the dropbox app (I'm about to uninstall PlainText).

Why does the article lead with a screenshot of a vulnerability that facebook took months to fix? Doesn't that mean it's an old issue that has nothing to do with this article? Isn't it a facebook bug?

I may be misreading both the article and the paper it's reporting on wrong, but this is not simply a WebKit isn't enforcing the same-origin policy thing. The vulnerability comes about because Android and iOS allow some inter-app communication (via Intents on Android, and URL schemes on both) that can be abused in some cases.

I don't know anything really about Android's Intents, so I skipped that section, but for URL schemes are were two possible vectors.

First, a malicious app could register the a URL scheme that another more popular app uses, e.g. something other than Facebook might register fbconnect://.

Second, if an app is using an embedded WebKit view, then an attacker could insert a reference to a URL scheme in some way, like <img src="fbconnect://..."> and the app that registered that URL scheme would be loaded automatically. That's the scary one.

I find it really surprising that Google didn't enforce same-origin restrictions on cookie-like data in Android. If anyone should understand basic web security, I'd expect it to be google.

The problem is that it has nothing to do with browsers. Calling this a violation of the Same-Origin seems really disingenuous. What it is is an OS whose applications are not completely sandboxed except through the approved Intents/Contracts. It's more of a flaw in the sandboxing and Intent design than anything else.

Intents that allow information to flow out of the application should only be capable of being invoked from inside the application. By the same context the only Intents that should be able to be invoked are those that send data into the application.

I find it really surprising that Google didn't enforce same-origin restrictions on cookie-like data in Android. If anyone should understand basic web security, I'd expect it to be google.

The problem is that it has nothing to do with browsers. Calling this a violation of the Same-Origin seems really disingenuous. What it is is an OS whose applications are not completely sandboxed except through the approved Intents/Contracts. It's more of a flaw in the sandboxing and Intent design than anything else.

Intents that allow information to flow out of the application should only be capable of being invoked from inside the application. By the same context the only Intents that should be able to be invoked are those that send data into the application.

I didn't really intend to imply anything about browsers. Apps that access web data should also have to play by same-origin rules, IMO. The article makes it sound as if a rogue sites accessed by an app can retrieve cookies and other data from another domain accessed by that same app:

Quote:

Both OSes fail to ensure that browser cookies, document files, and other sensitive content from one Internet domain are off-limits to scripts controlled by a second address without explicit permission

Even if it's not inside a browser, same-origin restrictions really should be applied. If data from one domain is supposed to be accessible to a second domain, then there should be an explicit permission for this placed into a signed app manifest or something. Based on my quick skim of the original paper's abstract, it sounds like the authors actually recommend such a system called Morbs.

I'm not sure how this plays with Intents (I am not an Android dev). However, it sounds like Intents are a form of late binding so that apps can inter-operate. How that relates to protecting data from one domain (app or internet) being read by another, I'm not sure.

Can somebody with more understanding of the matter please clarify:Is this a matter of the OS, the default browser or just any app?The article mentions the Google+ app explicitly and does not address this.Isn't an app (including browser app) responsible for implementing cookie support etc?My understanding was that e.g. iOS webkit is basically just a parser/rendering module.

I wonder if they've checked Windows Phone yet? Or the new Blackberry? Granted, those are pretty minor mobile platforms...

I would assume my windows phone not to get attacked, not because of its spectacular, award-winning security, but simply because no one uses them. You'll also notice no one attacking severe, easily-exploited weaknesses in the Turbo-Trac XR430 Wi-Fi Enabled Treadmill. (A product I just made up)

It does read more like an issue on the OS level (or API level ... I'm not a developer but is there a difference?) than browser. It's somewhat bothersome that folks haven't learned all these lessons yet but it sounds to me as though either a dev team figured that they weren't subject to the same issues as any modern browser or, more likely, they just didn't even think about it.

I would think (especially since Microsoft Research was involved) that if Windows Phone wasn't affected, they would have spelled that out. As someone else pointed out, either they're hiding it, or it's not. Until they clarify it though, no one should (or can) make any conclusions.