Comment by chatmasta | Hacker News Reader

Comment by chatmasta | Hacker News Reader

Parent Full thread

This is a fundamental security issue due to a combination of the OAuth protocol and UIWebView (and whatever the Android equivalent is), which I've posted about before [0]. Basically, the problem is that OAuth depends on web-based access granting, but an app has full permissions over the DOM of the WebView where the OAuth screen is. So you're entering your password into a WebView of a third party URL, but unlike a traditional safari page, the WebView is fully "owned" by the app, so the developers can inject arbitrary code into the DOM of the third party website.

There is no technical limitation to an app engaging in very nefarious activity. For example an app could modify the DOM on the sign-in screen to grab your password after you enter it. Of course the accountability of MITM and security reviews might mitigate this risk, but passwords are generally only a few bytes and could easily be obfuscated and passed surreptitiously over the wire.

I've seen a (quite popular) app implement this for facebook invitations, which should only have a limit of 50 friends, to secretly (in the background, without any action on your behalf other than logging in, or perhaps pressing a "continue" button) invite every one of your friends to download the app. Since facebook does not notify you when you send an inviation, you would not even know the app did this unless one of your friends who you invited asked you about it.

[0] https://news.ycombinator.com/item?id=11637209 (thanks molecule)

In iOS 9 there is SFSafariViewController which doesn't give such control.

Some providers (e.g. Fitbit) require you use this instead of UIWebView in order to access their API, presumably to avoid accessing the DOM.

Not sure exactly how they are enforcing this though, since they don't provide their own OAuth library.

Yeah, you could always override the method in the Fitbit library that implements that requirement.

> how do I permalink to a comment?

The comment's timestamp is a link.

> the WebView is fully "owned" by the app, so the developers can inject arbitrary code into the DOM of the third party website

Uh, seriously? I just suggested to our mobile team to integrate this way on Android (I implemented the OAuth 2 server).

I would've made the same suggestion to a 3rd party app vendor when the day comes.

A Chrome Custom Tab is probably the better way to go.

In summary, if you give a nefarious app your password it can do a nefarious thing?

I'm curious how exactly this is specific to the UIWebView implementation.

It's because the app has access to and control over the DOM of the UIWebView. Suppose some app called EvilGameFoo is asking you to authenticate with your Google account. They should kick you to a UI controlled by Google, which EvilGameFoo cannot in any way inspect or access, where you enter your credentials. Google then tells EvilGameFoo that they can vouch for you. Instead, UIWebView lets the app asking you to sign in via an identity provider inspect the DOM of the UK where you enter your credentials. Hence it lets EvilGameFoo read your password.

How are you supposed to know that it is actually a UI controlled by google and not a simulation of a UI controlled by google?

The OAuth model not only enables phishing directly even worse than that, it disarms people's natural skepticism towards phishing attempts. Its adoption was a terrible idea.

Well, on the web you're generally following redirects to a URL. You can verify the owner and authenticity of the host. (A phone app could kick you out to a browser app (not a web view) to authenticate.) Then after you've signed in and granted permission on, say, Google, Google will redirect you to a URL that the other app configured with Google. On a phone that URL should have a host or protocol that the app has registered with so your phone's OS will kick you back to the app after you signed in on the web browser.

Of course, you're absolutely right that it would be trivial to spoof, say, Google or Facebook or Twitter and collect credentials. I would _hope_ that behavior would be detected by Apple or Google during app security screening, but maybe not. Regardless, I totally agree with you about OAuth and security. It does present a lot of problems.

Google could send you a confirmation email which is the second factor in this oauth flow. It makes it more annoying, but more secure. It's always a trade off I guess.

> How are you supposed to know that it is actually a UI controlled by google and not a simulation of a UI controlled by google?

I have a certificate signed by Symantec guaranteeing that it's authentic!

Right, but what if they didn't use the UIWebView tactic and instead used custom chrome to submit the data. Couldn't they just tap it at that level?

Outside of the Android model where it does the auth for you upon request and only hands the app a token, I don't really see how you don't open yourself to this attack.

iOS really doesn't provide a way for other vendors in an inner ring of consumer trust and power to deal with this. While I'm not a fan of the decision to give full access to Pokemon Go, I didn't find it surprising that it did so on iOS and I had to make a conscious decision to "trust" Pokemon Go as part of the process.

Oh yeah, for sure, there are plenty of other ways a nefarious app could scrape a user's credentials during OAuth on iOS.

If UIWebView didn't allow the app access to the DOM then it wouldn't be possible this way. But,of course, the user has no way to know how the UI is implemented.

If an app does this, won't Google revoke their API key?

They have to detect it. The app could quietly collect credentials for months/years, and revoking the API key won't change those passwords.

Reply on news.ycombinator.com