Security Issue Focuses Spotlight on Insecure OAuth and OpenID Implementations

OpenID and OAuth 2.0, two open standards that are commonly used to allow users to log into a website using credentials from another website, have been in the spotlight over the past several weeks following the publication of a security flaw that could allow attackers to obtain user data.

The security flaw, dubbed "Covert Redirect", affects certain OAuth and OpenID implementations that specify the URL to which users should be redirected after authorization. Both OpenID and OAuth call out the risks associated with the redirect parameter, and require that redirect URLs be pre-registered and/or validated to prevent against the creation of a so-called "open redirector" which can be used to maliciously redirect the user to a location specified by an attacker.

Wang Jing, the PhD student at Nanyang Technological University in Singapore who publicized real - world examples of this flaw last week, suggests that "this vulnerability could lead to huge consequences if left unresolved." According to Jing, companies with vulnerable OpenID and OAuth implementations include Google, Facebook, Yahoo, PayPal and LinkedIn.

Bad timing

The issue of online security has been in focus lately thanks in large part to the Heartbleed bug that was found in the widely used OpenSSL cryptography Library. That bug, which is arguably one of the most serious in recent memory, forced numerous services to request that their users change passwords, and has been linked to the theft of sensitive data.

However, experts caution that heightened sensitivity to security issues should not lead to unnecessary alarm over OpenID and OAuth. John Bradley, a member of the OAuth working group, explained that "open redirectors happen all the time and cause a number of security problems for sites. The problems are not limited to OAuth" or OpenID.

Jing demonstrated a real-world application of the Covert Redirector vulnerability in a video posted to YouTube. The video shows how an attacker could target ESPN, which allows users to log in using their Facebook credentials. According to Bradley, however, OAuth wasn't the culprit it appeared to be. "ESPN didn't do anything wrong in its OAuth client," he told me. "A separate API in their domain not related to OAuth had a security mistake allowing redirection to URI outside of ESPN's domain." This bug has reportedly been fixed.

As for Facebook, Bradley points out that the company "is not conforming to the OAuth or OpenID Connect specifications." He believes that Facebook should migrate Facebook Connect to the OAuth 2 standard. Doing so would require significant effort, however, so in the meantime Bradley has posted suggestions for how developers can use Facebook Connect in a more secure manner than the default implementation.

Standards versus implementation

Bradley believes that some OAuth client developers may not fully understand the standard's security requirements and the tools for adhering to them. In an effort to help, he has submitted a draft that provides examples demonstrating the use of OAuth's state parameter, which allows state information to be stored securely during an OAuth authorization request and have it returned to the client when a response is issued. The primary intended use of the state parameter is to prevent Cross Site Request Forgery (XRSF) attacks, but this parameter can be used to protect any state information from modification.

"My hope is that if we are clearer with OAuth client developers there will be less pressure on the Authorization servers to relax security," Bradley told me.

Ultimately, the OpenID and OAuth security issue highlights the fact that implementation is everything. Open standards provide a blueprint and can create a healthy ecosystems in which security issues are addressed quickly and effectively. But open standards don't guarantee consistent or proper implementation, and as long as companies fail to fully adhere to standards and best practices, issues like this one will continue to crop up.

Be sure to read the next Security article: How to Secure Your REST API the Right Way