Hacker News Reader

Comment by arielweisberg | Hacker News Reader

And just like that I will never sign in with Google anywhere ever again. I just assumed that an app couldn't grant itself full permissions without notifying me, but now I can see why that might not be the case since they are free to present whatever UI they want in app.

In my dream world Google would revoke Niantic's API access forever in order to make an example out of them. Maybe, eventually, if they can prove that they didn't hoover up all the information they had access to they can be unbanned after a year.

Unlikely though considering they used to be a part of Google.

View on HN

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.

> In my dream world Google would revoke Niantic's API access forever in order to make an example out of them. Maybe, eventually, if they can prove that they didn't hoover up all the information they had access to they can be unbanned after a year.

I'm really glad you're not making that decision then. Banning some company based on their use of public, legal APIs would be an absolutely toxic decision for Google's platform.

It's Google's fault for allowing this kind of access with no notification (yes, the fault here might lie somewhere in OAuth, but there's plenty that Google could do to make this less serious). Don't blame people for leveraging options at their disposal.

Elsewhere in the thread it is alleged that this is a bug (or misbehaviour) with Google's iOS authentication library. It's possible that Niantic is not requesting any permissions and the library defaults that to 'full access' and not 'no access'.

I've yet to see it confirmed, though.

This issue only affects apps though. When granting OAuth permission via the web, you are actually redirected to google's website, and then afterwards redirected back to the site you were on.

Google recommends using the browser workflow for installed apps too.

https://developers.google.com/identity/protocols/OAuth2Insta...

Which probably isn't very helpful, as lots of users won't notice whether they are using a browser or not.

Does anybody know how Pokemon Go ends up interacting with accounts that have 2 factor authentication turned on? I sure wouldn't type my main password into some app, I'd at least use an app password:

https://support.google.com/accounts/answer/185833?hl=en

2 Factor works. I'm forced to log back in when ever there is server troubles, which is annoying, but what ever.

Did you try using an App password? Doesn't seem to work for me

No I haven't tried it.

The other day someone's web app I clicked on, and it automagically signed me in with Google and added itself to my connected apps. Cloudcraft.co, I think it was. When I hit their signup link, it auto-signed in with Google without me even clicking their Google button.

After I disconnected it, it didn't behave that way a second time. So I am kinda mystified what happened there. But it was pretty strange.

Could the app be intercepting the confirm screen and auto-agreeing w/o user interaction?

I am very hesitant to accuse the app of doing something intentionally shady like that. I don't really :know: what happened, and I couldn't replicate it myself after removing the app from my account and visiting it again.

> I just assumed that an app couldn't grant itself full permissions without notifying me, but now I can see why that might not be the case since they are free to present whatever UI they want in app.

Is that the case? Doesn't this still require going through the standard prompts?

Anecdote: On Android 6.0 the Pokemon Go game requested 4 permissions on first launch. Account, Camera, Storage, and one other I believe. I had to individually approve each one.

That's just access to your phone, not your Google account. Those permissions don't cover the app's ability to read your email.

I also do not have an entry on my Google permissions page (https://security.google.com/settings/security/permissions?pl...), this appears to be an iOS only bug, explaining why no Android user can recreate this bug

I can verify this. I logged in with Google and see no permission given to the app.

I do have an entry on that page!

"Pokemon Go Release - Has full access to your Google account"

Revoking access now. Glad I read HN!

According to the article, it does not.

or just use a burner email for stuff you don't trust

Reply on news.ycombinator.com