Modal Title

IT Director Yoda: Unlearn What You Have Learned About Facebook And OAuth

May 5th, 2014 11:46am by
Featued image for: IT Director Yoda: Unlearn What You Have Learned About Facebook And OAuth

The latest case of the-Internet-security-sky-is-falling came out Friday in the form of an OAuth open redirect security hole blog post. Like so many recent overblown security holes, the only thing remotely new is that we have rediscovered how reporters on a Friday follow a strict publish-first-and-ask-questions-later methodology. It’s a panic more than a fundamental security flaw like Heartbleed.

That said, just because a hole is old and has easily-deployed preventions out there doesn’t mean it is harmless. Frighteningly, what the latest OAuth hole has going for it is that plays on security advice that users have been given for years, namely that they need to look at the referring page of any link before clicking on it. In short, they need to make sure it’s going where it’s supposed to be going. This hole takes advantage of that and displays a referring URL that looks just right—but it simply sends the user somewhere else.

It also leverages another Internet 2014 reality, which is a massive over reliance on third-party sites and systems. The site an end-user is visiting—say Facebook, Toyota or Chase—can have ideal security but this hole will exist in some obscure (and sometimes not-so-obscure) site that is connected. To effectively fight this newly-discussed OAuth hole, developers must rethink how they use third-parties as well as get users to rethink what they do before deciding to click on a link.

As IT Director Yoda would have said: They all must unlearn what they have learned. (Note: if you just now clicked on that link just because you recognized YouTube and chose to trust our core site, you may have some unlearning to do yourself.)

Let’s first delve into the hole itself. The post that started it all talks more about the implications of the hole than the hole itself. The essence is that when a user authorizes a site to do something, this tactic allows a thief to re-use that permission.

A post from back in February (and, yes, this is why nothing really new happened lays out more details.

That report sums up the attack as the script “redirects to about:blank URL (about:blank always inherits parent’s origin). And we can access document.referrer containing the previous URL Auditor just blocked. Facebook had ‘1; mode=block’ header. Now it’s 0; because of us (Auditor is dangerous, new vulns will be posted soon). Sadly, this bug report was marked as sev=low by Chrome security team and no bounty granted. It’s not patched yet. We used 2 bugs: dynamic redirect_uri and dynamic response_type parameter. Response_type=code is the most secure authentication flow, because end user never sees his access_token. But response_type is basically a parameter in authorize URL. By replacing response_type=code to response_type=token,signed_request we receive both token and code on our redirect_uri. redirect_uri can be not only app’s domain, but domain is also allowed.

In our exploit we used response_type=token,signed_request&redirect_uri=FB_PATH where FB_PATH was a specially crafted URL to disclose these values.”

That link delves into more specifics, but it was properly dismissed as old and defendable in some astute pieces. (My favorite is this John Fontana piece from ZDNet;.)

The fact that there are ways to avoid this hole, however, misses the point. This is the latest reminder that end-users need to have concrete ways to know if a link is legitimate. But given that putting the onus of authentication on end-users is never an especially safe strategy, the real repair needed is having more strict control of what third-parties can do with your site visitors.

How much penetration testing do you do with the code of your partners? And, for that matter, their partners? What testing do you require they perform as part of your contracts? Remember that any action performed by a third-party on your site will be seen as having been performed by you—at least as far as your customers are concerned.

Yes, this would be a huge increase in workload, which is why it’s so rarely done. But if you are trusting these vendors with almost all of your revenue, shouldn’t you truly know what their code is doing, even if your third-party itself doesn’t?

Image credit via Creative Commons on Flickr

Evan Schuman has covered IT issues for a lot longer than he’ll ever admit. The founding editor of retail technology site StorefrontBacktalk, he’s been a columnist for Computerworld,, RetailWeek and eWeek. Evan can be reached at and he can be followed at

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.