The Short Answer is ‘No’
Now that Heartbleed has become the new measuring stick for vulnerability disclosures, I have had several people ask me, “Is this OpenId/Oauth thing the next Heartbleed?”
The long answer, as Run DMC once said, is “It’s Tricky, Tricky, Tricky, Tricky”. The TL/DR (too long/didn’t read) answer is “No”.
CNET first reported these new “serious security flaws” on May 2, 2014. And although it’s never a great idea to stir-up the security echo chamber on a Friday morning -- at least this wasn’t as apocalyptic as Heartbleed (despite the large doom and gloom coverage).
Read on for a little more clarity…
First Stop: Basic Training
Unless you have been living in a hostel for the past few years, you have all seen the option: “Sign in to [PickYourSite] using your Facebook, Google, etc. credentials.” This option allows each of us to keep fewer logins and passwords stored in our heads for the plethora of sites we visit online.
In other words, OAuth/OpenId are ways for you to use an account that you have at one site, e.g. Facebook or Google, to grant access to resources at a participating site without having to re-register or create multiple accounts. OpenId is usually reserved using one identity for multiple sites and OAuth as a way to allow an application to access one’s account without giving the application your specific login credentials, however, they can -- and have -- been used as functional equivalents.
The Good, The Bad, and The Ugly of the Redirect
The good news: Unlike OpenSSL, this isn’t a bug that is actually in OAuth/OpenID, which are framework specifications, and not specific libraries.
The bad news: because it is not a “bug”, it isn’t easy to fix.
The exposure basically boils down to three things:
- A failure of certain websites to disallow open redirects. An open redirect can allow an attacker to essentially hijack an application and redirect the user from one web location to another -- unknowingly -- to a new and malicious site controlled by the attacker. This vulnerability is often used in phishing attacks to get users to visit malicious sites without them realizing it.
- OAuth/OpenID fundamentally relies on redirects and it requires participation of all interested parties (User, Consumer, and Service Provider).
- Consumers and Service Providers need to fully understand the issue in order to use redirects properly.
Honey, Where Are My Keys?
We’ll use a simple example to further clarify the issue. Let’s say, you are a developer. You want to allow users to login to your application WhereAreMyKeys? with Facebook so that your app can leverage specific information in their timeline.
In this case you would use Facebook’s OAuth services to have the user grant permission to your WhereAreMyKeys? app using their Facebook credentials. The request then goes directly to Facebook. Next, you will specify a redirect-url for Facebook to contact WhereAreMyKeys? once the user has successfully authenticated with their credentials.
All seems great, until you think about what an attacker would do. What if the attacker was able to specify a different URL to return to? Instead of redirecting to WhereAreMyKeys.com, you are now directed to WhereAreYourKeys.com/mykeys -- a site the attacker controls. This malicious redirect would give an attacker access to your Facebook account data, assuming that you granted access in the first place.
Once again this isn’t a new issue. In fact, one of the preventative measures that Facebook has in place is essentially a domain verification step making sure that the site you are being re-directed to has been registered with Facebook, thereby preventing an attacker from redirecting to a different domain. This of course works unless you, as the developer of WhereAreMyKeys?, are redirecting back to another portion of your own site using a separate redirect mechanism. Unfortunately, this is where the “latest” attack focuses.
Which brings me back to why this is hard to fix and also not as big of a deal. With OAuth/OpenId, the attack steps are known and traceable. With Heartbleed, access to critical data could be obtained without engaging the user and without leaving a trace.
Between the Rock and the Hard Place
As I mentioned before, everybody has a part to play in this issue, starting with the user not granting access to their trusted OAuth/OpenId providers for any old website (e.g., WhereAreMyKeys?). This is easier said than done as the behavior is becoming a conditioned response. None of us really want to keep signing into different sites that require new passwords. We hate having to remember all of the user names and passwords for different sites, and we prefer to take the easy path: we just use our Facebook user ID and password, because it is easy to remember.
I tried explaining this to my parents and they said, “You mean when Facebook asked me to authenticate I should say no all the time?” Ugh. Ugh. Ugh.
So, you ask, “What if service providers like Facebook could ‘whitelist’ all redirect-urls?”. While that might sound easy, in practice, given the number and diversity of applications that take advantage of this “grant access” and “redirect” action, the scale of the issue is not easy to deal with.
As a best practice, we should expect that applications wanting to leverage OAuth/OpenId should not allow any type of open redirect on their website. I would argue, given the nature of this style of attack, that making this a condition for using a Service Provider’s service should be part of the developer terms and agreements and the provider should use application revocation as a stick to enforce compliance. I mean, it is 2014...this should not be an issue.
Why this is not as big a deal
The same reasons this is hard to fix are also why this isn’t as big a deal as originally portrayed. Don’t get me wrong, if you meet all three of the conditions above, it can be a big deal. But this really affects a much smaller set of applications. As you can understand now, how users access those applications in practice is not nearly as ubiquitous as Heartbleed.
As users, we all still have to browse to a potentially dangerous website and grant access. Just think before you click.
Want More Juicy Details?
Mashable also had a great write-up on why this isn’t as big an issue and the fact that it isn’t technically new. I would also recommend reading an excellent write-up of the technical details for OAuth/OpenId by Danny Thorpe.
