[Vanilla_Salt]

> 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]

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.