By Christina Warren From Mashable

Breathless reports of a new security flaw affecting OpenID and OAuth — the technology that powers the identity logins for services such as Facebook, Microsoft, Google and LinkedIn — hit the news Friday. Dubbed “Covert Redirect,” the flaw could enable malicious sites or links to grab a user’s login information.

The announcement of Covert Redirect is straight out of Heartbleed’s marketing manual, coming with both slick website and fancy logo. Coupled with the widespread usage of OAuth and the growing awareness of potential security threats, Covert Redirect certainly sounds bad.

Already, we’re seeing news organizations report this as the next major web security crisis.

Fortunately, Covert Redirect is not the next Heartbleed Covert Redirect is not the next Heartbleed. In fact, from what we can ascertain, the Covert Redirect “flaw” isn’t even new. Moreover, classifying Covert Redirect as a vulnerability with OAuth 2.0 and OpenID is incorrect.

That isn’t to say that a potential problem doesn’t exist — it does and we’ll discuss how it works — but it is important to understand that this isn’t a new discovery and that companies such as LinkedIn, Facebook and Google are already aware of the potential concerns.

OAuth and OpenID 101

OAuth is an open standard for authorization. It’s designed as a way for users to sign in or sign up for other services using an existing identity of a site such as Google, Facebook, Microsoft or Twitter. OpenID is a similar protocol also used for single sign-on (SSO).

These protocols are what companies use to make it easy to sign in for multiple services without having to create several new accounts. When you sign up for Flipboard using your Twitter account or sign into Pinterest using your Facebook account, OAuth is the technology behind the scenes that makes it all work. OAuth 2.0 is the next version of the OAuth protocol, and it’s still in development.

It’s worth noting that OAuth 2.0 is really more of a framework than a set protocol. That means identity providers can pick and choose what features of the protocol they want to use and they can further customize it for their own needs.

This is a very big different than OpenSSL — which is a set of libraries that developers can drop into their software. That isn’t to say that OAuth 2.0 libraries don’t exist — they do — but most of the major service providers make their own changes and implementations.

That’s why it’s irresponsible to classify the Covert Redirect flaw as an OAuth 2.0 vulnerability. The flaw is not within the OAuth 2.0 spec, but rather in the way Facebook has implemented the spec into its own systems.

Resurfacing a known problem

Wang Jing, a Ph.D student from Nanyang Technological University in Singapore is credited as “discovering” Covert Redirect and creating its website and logo. He also published a video of the exploit in action on YouTube.

On his blog, he describes “discovering a new method to hack Facebook OAuth 2.0” using its redirect parameters. In short, Wang has managed to show that he could trigger a Facebook login to appear from a malicious link.

Don’t let the fancy logo fool you, this threat isn’t as bad — or as new — as you think.

As an example, if you visited a phishing site that looked like another service — perhaps one with Facebook login — clicking on the Facebook login button would actually send those details to the attacker.

But this isn’t a new realization. Jing’s discovery appears to be very similar (or identical) to a method Egor Homakov discussed in March 2013.

Homakov is a security consultant who has reported Facebook security bugs in the past. Along with Nir Goldshlager (who also has a history of discovering Facebook security flaws), he outlined how Facebook logins can be hijacked by tampering with the redirect_uri parameter in the OAuth spec.

This is possible, presumably, because of the way Facebook integrates with OAuth 2.0 with its Graph APIs.

Developer Alex Bilbie frequently writes about OAuth 2.0 and how to best implement it. Last year, a spate of OAuth-related hijackings led to discussions that the framework itself is insecure. That’s not accurate. The problem comes with how certain companies choose to implement OAuth — not with the framework itself The problem comes with how certain companies choose to implement OAuth — not with the framework itself, Bilbie explains.

In the case of Homakov’s redirect_uri attack, Bilbie noted that the potential for these types of phishing-redirects was a possibility outlined in the OAuth 2.0 spec itself.

In fact, there is an entire section of the OAuth 2.0 threat model specification that outlines exactly what Homakov (and Jing) have detailed.

If the authorization server allows the client to register only part of the redirection URI, an attacker can use an open redirector operated by the client to construct a redirection URI that will pass the authorization server validation but will send the authorization code or access token to an endpoint under the control of the attacker.

The solution is to require all clients (apps) to use a whitelist of redirect URIs, in order to prevent an attack from a dynamic URI.

So why doesn’t Facebook do this now? Bilbie has a theory:

I suspect partly why this has happened to Facebook is because when they launched their Graph APIs back in 2010 they secured them with draft 5 of the OAuth 2.0 specification. As the specification changed over it’s 27 drafts they already had clients hardcoded with specific parameters that couldn’t be updated easily and so therefore they had to make a choice to allow the above parameters that were used in the attack to accept dynamic and non-canon values.

In other words, when Facebook first launched its Facebook login feature, it was relying on a very early draft version of OAuth 2.0. Changes — such as requiring a registered redirect URI or a whitelist check — came after their implementation of the framework existed.

To update their implementation now would mean breaking lots and lots of potential existing client implementations.

That aligns with what Facebook’s response to Jing. Jing says Facebook told him that “[they] understand the risks associated with OAuth 2.0. However, short of forcing every single application on the platform to use a whitelist, [fixing the vulnerability] isn’t something that can be accomplished in the short term”

It is worth noting that websites and apps that use Facebook can utilize a URI whitelist for redirects, it just isn’t required. Existing sites and applications can prevent a malicious site from trying to use their login IDs in a this type of attack by registering redirect_URIs in their Facebook apps.

What’s the real danger?

In the right set of circumstances, it is currently possible to use a phishing site to hijack Facebook login credentials. Depending on the OAuth 2.0 implementation, this could be possible on other services too.

It’s important to note, however, that in order to take advantage of this vulnerability in the first place, a user has to click on a link or visit a malicious website. And not only does a user have to click on a malicious link, they have to then click on a Facebook login button and agree to authorize the login and release of information.

That puts this kind of threat on a much different level than something such as Heartbleed. It’s not even as bad as the security flaw Microsoft just patched in Internet Explorer.

To avoid offering up information to a malicious website, users should only log into Facebook or other services through sites that they trust. If a site looks sketchy, don’t do it. Standard anti-phishing practices apply here.

Of course, it goes without saying that Facebook should update its specification as soon as it can. Even if it means breaking some sites and apps — this is a flaw that has existed for far too long.

Last month, LinkedIn required all of its developers that use OAuth 2 to register redirect URLs.

The Heartbleed effect

For me, the most fascinating aspect of Covert Redirect is the way it attempts to ape the “success” of Heartbleed.

As Mashable Editor-at-Large and Chief Correspondent Lance Ulanoff noted last month, Heartbleed really is the first Internet security superstar.

Heartbleed’s infamy came from the solid name, easy-to-read website and enticing logo. Unlike most security vulnerabilities with esoteric naming conventions and difficult-to-comprehend security bulletins, Heartbleed had its own identity, and its own brand.

Heartbleed was exactly the type of security flaw that needed a strong brand identity. If it had been set up like any other virus warning, it’s possible the significance, potential impact and severity of the flaw could have been overlooked. As it stands, one of the best takeaways from Heartbleed is the role it has played in raising overall security awareness.

This is why I’m troubled by campaigns such as Covert Redirect. Yes, the potential threat is real — but this is not the sort of flaw deserving of the “Heartbleed treatment.” this is not the sort of flaw deserving of the “Heartbleed treatment.” Not only is the flaw not new, it’s well-known by the stakeholders responsible for implementing an authorization spec.

The branding and identity of Heartbleed working in part because of the novelty behind the concept of giving a bug a logo, name and website. If that happens too much — I fear users will just tune out any security announcement, ignoring those that are really problematic.

A month after Heartbleed, many users are on high alert for any security threats. That’s a good thing. We should all be more aware and alert of the potential dangers that exist. But that doesn’t mean we need to treat every bug like it’s doomsday. Even if it does have a logo.

IMAGE: MASHABLE COMPOSITE. ISTOCKPHOTO HIDESY, COVERT REDIRECT

IMAGE: WANG JING

For more on this story go to: http://mashable.com/2014/05/02/oauth-openid-not-new-heartbleed/?utm_campaign=Feed%3A+Mashable+%28Mashable%29&utm_cid=Mash-Prod-RSS-Feedburner-All-Partial&utm_medium=feed&utm_source=feedburner&utm_content=Google+Feedfetcher