3 ms·

Dark patterns like what?

chatmasta 4y ago
I'm long gone out of the mobile industry, but circa 8-10 years ago, I was aware of multiple top ranking iOS apps which were abusing OAuth login by opening the identity provider login screen inside an in-app browser, which meant they had full control over the DOM, and could e.g. circumvent Facebook protections to silently invite all your friends to the app using "invite to game" functionality. You would never know it happened because you wouldn't get any notification unless someone reached out and asked you why you sent that invite. And FB conveniently sorts friends so that the first 50 are your close contacts, which these apps could skip sending the invite to, under the assumption that your random acquaintances wouldn't bother reaching out about yet another notification they got from you. I didn't see any of them grabbing the password, but they easily could have. I'm pretty sure Apple has since closed this loophole by enforcing that apps perform OAuth in a browser where they can't control the DOM, but I'm not sure - I got as far away from that scene as I could...
- Vanilla_Salt 4y ago
  > I'm pretty sure Apple has since closed this loophole by enforcing that apps perform OAuth in a browser where they can't control the DOM, but I'm not sure Apple are not restricting OAuth in an embedded web view, at least not on a software level. I have worked on an application that injected JS into the OAuth window for non malicious style purposes. It is possible they're rejecting apps from the store for this behavior, but I wouldn't know.
  - chatmasta 4y ago
    I think they may be enforcing it for certain high-profile OAuth IDPs, e.g. Facebook. At least, as a user, I've noticed a difference in the feature, i.e. "TotallyNotMaliciousApp wants to Authenticate with Facebook" which seems to open some more locked-down version of the browser in a view that I assume is not modifiable by the app that initiated it. But I'm not an iOS developer, so I have no idea what feature is driving this, or what the policies are around using (or not using) it. What I found interesting about this technique is that it's difficult to classify as a bug, aside from the obviously malicious scenarios. But even then, who is being exploited? Everything is working as designed - apps should be able to control the DOM in their in-app WebView, and Facebook should expect that users on an OAuth screen may send them untrusted input. It's only when the two contexts are combined that an exploitable "bug" emerges, in such a way it's not clear whom to blame between Apple and Facebook. The only clear malicious entity is the app publisher. So from that perspective I guess you could blame Apple for letting it through review. But some apps go to great lengths to trick the reviewers in this regard, and there are many ways to obfuscate the injection, including loading it remotely or conditionally based on user IP, time of month (is a release currently under review?), etc.

I'm long gone out of the mobile industry, but circa 8-10 years ago, I was aware of multiple top ranking iOS apps which were abusing OAuth login by opening the identity provider login screen inside an in-app browser, which meant they had full control over the DOM, and could e.g. circumvent Facebook protections to silently invite all your friends to the app using "invite to game" functionality. You would never know it happened because you wouldn't get any notification unless someone reached out and asked you why you sent that invite. And FB conveniently sorts friends so that the first 50 are your close contacts, which these apps could skip sending the invite to, under the assumption that your random acquaintances wouldn't bother reaching out about yet another notification they got from you. I didn't see any of them grabbing the password, but they easily could have. I'm pretty sure Apple has since closed this loophole by enforcing that apps perform OAuth in a browser where they can't control the DOM, but I'm not sure - I got as far away from that scene as I could...

Vanilla_Salt 4y ago
> I'm pretty sure Apple has since closed this loophole by enforcing that apps perform OAuth in a browser where they can't control the DOM, but I'm not sure Apple are not restricting OAuth in an embedded web view, at least not on a software level. I have worked on an application that injected JS into the OAuth window for non malicious style purposes. It is possible they're rejecting apps from the store for this behavior, but I wouldn't know.
- chatmasta 4y ago
  I think they may be enforcing it for certain high-profile OAuth IDPs, e.g. Facebook. At least, as a user, I've noticed a difference in the feature, i.e. "TotallyNotMaliciousApp wants to Authenticate with Facebook" which seems to open some more locked-down version of the browser in a view that I assume is not modifiable by the app that initiated it. But I'm not an iOS developer, so I have no idea what feature is driving this, or what the policies are around using (or not using) it. What I found interesting about this technique is that it's difficult to classify as a bug, aside from the obviously malicious scenarios. But even then, who is being exploited? Everything is working as designed - apps should be able to control the DOM in their in-app WebView, and Facebook should expect that users on an OAuth screen may send them untrusted input. It's only when the two contexts are combined that an exploitable "bug" emerges, in such a way it's not clear whom to blame between Apple and Facebook. The only clear malicious entity is the app publisher. So from that perspective I guess you could blame Apple for letting it through review. But some apps go to great lengths to trick the reviewers in this regard, and there are many ways to obfuscate the injection, including loading it remotely or conditionally based on user IP, time of month (is a release currently under review?), etc.