3 ms·

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 Googl

by skewart 10y ago

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.

bradleyjg 10y ago
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.
- skewart 10y ago
  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.
  - chii 10y ago
    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.
- wtbob 10y ago
  > 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!
KirinDave 10y ago
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.
- skewart 10y ago
  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.

by skewart 10y ago

bradleyjg 10y ago

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.

skewart 10y ago
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.
- chii 10y ago
  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.
wtbob 10y ago
> 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!

KirinDave 10y ago

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.

skewart 10y ago
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.