Covert Redirect mostly hype and certainly no Heartbleed

Known issue is mitigated in OAuth, OpenID specs; implementation problems are at issue
Written by John Fontana, Contributor

A researcher's contention of security flaws in OAuth and OpenID has serious flaws of its own, according to those familiar with the specifications.

News of the security issues hit hard Friday claiming the two identity specifications were flawed and user log-in information and other data could be stolen by hackers. It immediately drew comparisons to Heartbleed in terms of its ability to shake the foundation of the Internet.

But the bug, dubbed the Covert Redirect Vulnerability, is only like Heartbleed in that it came pre-packaged with a manufactured name, a website and a polished logo.

The flaws “discovered” by Wang Jing, a Ph.D student from Nanyang Technological University in Singapore, are already known quantities and creators of the specs have already devised mitigation. The problems don’t lie with OAuth and OpenID, but in web site implementations that allow something called an “open redirect” that allows the web browser to send credentials back to a URL that does not match the URL that originally requested the credentials.

OAuth, a framework, and OpenID, a protocol built on that framework, are key plumbing pieces for secure log-ins and secure sharing of access control credentials across Internet domains. The two are used by the likes of Google, Microsoft and LinkedIn. Facebook uses OAuth and something similar to OpenID.

Jing, who released videos that walk through the exploit, shows how Facebook’s OAuth implementation is hacked using an open redirect parameter that sends a user's access token to a malicious site instead of the one that originally requested the credentials.

“Open redirectors are the main challenge, and this is actually recognized and mitigated in the final version of OAuth,” said Eve Maler, an analyst with Forrester Research, who has used the OAuth framework to develop a protocol called User Managed Access. “Keep in mind that no one is checking for Facebook (or other) conformance to the final OAuth RFC, so it appears a contributing factor to the problem is the lack of conformance testing and reporting,” said Maler. She says a discussion on conformance needs to get started.

Some conformance work is being done by those who recognize the problem is not the spec, but the implementations. In March, LinkedIn asked developers to register the OAuth 2.0 redirect URLs for their applications so they would conform to the OAuth specification concerning open redirects. The deadline was April 11th and those who did not meet it had error messages in their applications when users tried to sign-on using their LinkedIn credentials.

Guidelines for using a redirect_uri command are part of a document titled “OAuth 2.0 Threat Model and Security Considerations” that was published in January 2013 by the Internet Engineering Task Force. (The IETF standardized OAuth 2.0 in Oct. 2012). Torsten Lodderstedt of Deutsche Telekom, Mark McGloin of IBM and Phil Hunt of Oracle authored the Threat Model document, which includes a section called “Validate Pre-Registered redirect_uri."

The section states:

As per the core spec, every actual redirect URI sent with the respective "client_id" to the end-user authorization endpoint must match the registered redirect URI. Where it does not match, the authorization server should assume that the inbound GET request has been sent by an attacker and refuse it.”

John Bradley, an OpenID Foundation board member, said Jing ignored the security mitigations in OAuth and OpenID that prevent open redirects. (Bradley has a more detailed description on his Thread Safe blog).

In the video posted by Jing, “he captures (at 3:55 in the recording) the URL from the browser bar and pastes that into the text editor,” said Bradley. “This requires the complicity of the user to steal their own access token.”

Disclosure: John Bradley and I work for the same employer.

Editorial standards