Why in-process OAuth is not a security vulnerability

A couple days ago a post by Craig Hockenberry made the rounds, leading to many blogs latching onto it with sensationalist headlines like “Developer warns of yet another big iPhone security flaw” and “In-app browsers are insecure: use Safari for sensitive browsing”. Never mind the completely inappropriate platform-specificity of these claims, the main question is… are they right?

In short, no. There’s no news here. It’s sort of like saying, “iPhone text input control is vulnerable to key logging!”. It’s just silliness. Yes, anything you type into an app is received by that app. No, this should not surprise anyone (*especially* developers!).

Here’s an exercise. Find a non-technical user, have them open an app which uses in-process OAuth (let’s say, Tinder), and ask to whom they’re giving their password (in this case, their Facebook password). How many would say anything other than Tinder? Is this a security problem? Of course not, this user trusts Tinder not to misuse their credentials. They don’t really know or care whether Tinder uses in-proc or out-of-proc OAuth. Their eyes would gloss over if you even posed the question.

Does out-of-proc OAuth have to mean launching a browser? Nope! On iOS it might. On Windows and Windows Phone, the WebAuthBroker API provides a way to do this which presents a dialog (running in a separate executable) on top of the app. That dialog then hosts the OAuth page and provides a way for the app to receive just the parameters passed to the OAuth callback URL.

Does this make an app that uses the broker (or the ridiculous Safari gymnastics which requires the user to copy and paste a code) more secure? No. Well, very very marginally. Hypothetically, if the app has a code injection vulnerability, the out-of-proc auth may protect your credentials. The chances of an app you use having such a vulnerability (which can be exploited *before* you enter your password – something most OAuth apps do on first launch), with a website the attacker knows you’re going to log into, before the app is updated to fix the problem or kill-bitted by the store, is pretty darn low. And even without this theoretical attack vector, an app with this kind of independent vulnerability can already do significant damage. You’re actually *more* likely to be affected by an exploit against Safari. Or against an app which takes your credentials directly, like the official Facebook app, for example. They’re just much more tempting targets than some small rando developer app using OAuth.

(I’m going to gloss over my suspicion that the WebAuthBoker dialog and the app’s input queues are tied since it’s almost certainly an owned window – maybe someone thought of that, but I didn’t CR it and the number of people I’d trust to catch that is small)

Why does Windows offer the WebAuthBroker then? Truthfully, the main reason that I know of was that the original Win8 release didn’t have WebView support for JS apps (which constitute most of the in-box apps like Mail, People, and the Bing apps). Without that, the only way to embed a web page was with an iframe, and most OAuth pages intentionally don’t support iframe hosting. So why did Win8.1 add WebView support to JS apps? Because installing an app is an indication of trust beyond that of browsing to a random website. Apps are installed. They’re sandboxed, yes, and user confidence in being able to try apps is important. But just as you shouldn’t type your bank info into a finance app you don’t trust, you shouldn’t type your Facebook password into one either.

Now for a very important question: Does the WebAuthBroker or Safari gymnastic routine mean you can type your password into a dubious app? Abso. Lutely. Not.

Why not? Well, first and foremost, we’re talking about opt-in mechanisms. A malicious app developer isn’t going to opt-in. A trustworthy developer like Craig opting in does not make *his* app meaningfully more secure. And it certainly doesn’t make anyone else’s safer to use!

What if Apple made out-of-proc OAuth *required*? Well, assuming they created something like WebAuthBroker so that the UX didn’t utterly suck, this would still be a logistical nightmare. You’d need some crazy well-trained reviewers to detect that an auth experience was truly out-of-proc, and how would you distinguish these from first-party apps with native auth fields (like your run-of-the-mill official Twitter and Facebook apps), or handle apps with built-in navigable browser controls (like news readers), or apps which turn on this functionality remotely after being approved? Or hell, a third-party browser like Chrome, or a password-management app like 1Password? The answer is simple: You can’t.

What if users were trained to understand the difference between in-process and out-of-process separately-sandboxed auth?

Hahahahahahahaha. You’re a funny one.

No seriously, what if you did? It still wouldn’t help. An app can spoof any of these interactions (the OS WebAuthBroker pop-up, or even the Safari app switch), trivially. Yeah, if you’re an advanced user who is *really paying attention* you could probably catch the spoofing. If you could train regular users to be this attentive and skilled at discerning spoofed app UI (particularly on devices where apps own every pixel of the display!), the world would indeed be a vastly safer place. And unicorns would dance in the streets, farting rainbow clouds of life-giving pixie dust. Good luck bringing that about.

Oh, and lest you think you’re getting off easy, you don’t just have to solve spoofing of the out-of-proc UX (whatever form it takes). An attacker can just as well spoof the actual web form (having Safari or WebAuthBroker host www.twltter.com or evilurlyoullneversee.com which looks just like twitter’s login page). So you have to train the user or the app reviewer to detect *both* of these cases. The WebAuthBroker doesn’t display the URL or domain *anywhere* (which the IE team would not have let fly, but they didn’t own it), and last I knew Safari lets web sites hide the address bar (which IE at least explicitly shows on navigation).

So what should be done? Mainly: People should not give private information and passwords to apps they don’t trust. If they become suspicious of an app they’ve given such info to, they should change their passwords immediately. App stores should monitor reports of such apps and revoke / kill-bit them, and ban the publishers. And you know what? That’s exactly what they have been doing for years. Is there a big attack being carried out against iOS users? Or users of any mobile platform? Not that I can find.

So what’s the appropriate news headline? So far as I can tell, none. If it’s a slow news day, maybe “Apple doesn’t certify apps which make you do unnecessary app switching gymnastics to log in”. Would have to be a pretty slow news day, I’d think.