The New OAuth and OpenID Flaw (Covert Reunion AKA Covert Redirect)… How Dangerous Is It Really?

It looks like we are living in the era of security flaws. Recently it was HeartBleed, and now it is about the OAuth and OpenID Flaw discovered last week and termed Covert Reunion or Covert Redirect. Published by Wang Jing, a Ph.D student from Nanyang Technological University in Singapore as Covert Redirect, this flaw states that the redirect URI (Uniform Resource Identifier) can be manipulated in a way that malicious websites can easily get access to tokens (provided by Facebbook, Google, Microsoft, etc. to access user information) and use it for their benefit. In a purely hypothetical example, let’s say the ESPN website asks a user to leverage their social identity from Facebook, Google+ or other account to access it’s content. Some malicious websites can actually modify the redirect URI and present itself as a ESPN website in order to gain access to the user’s information from via their social accounts. Note, in this example the ESPN website should already be authenticated in the user’s system.


But the question arises, “Is it really that serious?” It’s worth noting that OAuth 2.0 is really more of a framework than a set protocol, and this problem was well known by implementors. 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. OAuth2 explicitly requires registration of URI’s (AKA whitelist) redirect URI’s and a decent implementation should meet this requirement in order to protect from a dynamic URI.  Major companies like Google acquired Postini, Microsoft uses Baracauda for this whitelist purpose only, and Facebook prevents from setting redirection URL outside the configured domain. But, forcing each of them to use whitelist and to update their implementation would mean breaking potential existing client implementations.

Even then, the attacker can work around the domain whitelist. One solution can be to always guard them with additional sign-in credentials derived from the URL and a private verification known only to the user. Either way, standard anti-phishing techniques are recommended and the best advice is to be wary of following links that immediately ask you to login to Google or Facebook.  If this occurs, immediately close the new browser tab or window in order to prevent redirects. 

Many suggestions have been offered since this this vulnerability made headlines. All of the gaming and app companies use the tokens for million of users for access, but there was never (until now) a widespread problem. Along with access tokens, they also consider other parameters such as the user’s EMEI, or mobile serial number for a device, as a part of post-process plugin signature. Or, a technique similar to Reverse DNS could be applied as OAuth v1 does not have this flaw. Even though this problem and potential impact may be considered minimal until new information arises, still adding post-processing validation on every connection can help us limit any potential impact.