A recently reported new “vulnerability” in OAuth appears to be anything but.
That unkind assessment has come from security specialists after a flaw called “Covert Redirect” made headlines that conflated the flaw with the Heartbleed vulnerability, a major security risk that legitimately sent administrators scrambling to fix their websites.
PhD student Wang Jing from Nanyang Technological University reported the flaw Saturday and showed how it allowed attackers to phish users and obtain their tokens.
In videos, he demonstrated how the trick applied to the OAuth implementation in Facebook where OAuth tokens were sent to a malicious site.
Websites using the platform issued login requests to authentication sites like Google and Facebook which then prompted users to log in. An access code was subsequently handed over by redirecting the users’ browser to a URL from the requesting website with codes passed in URL parameters.
User pwnage occurred when open redirects shipped off the information to any URL in the parameters. Dell authorisation architect Danny Thorpe explained the attack in the example: “https://example.com/redirect/?original_page=http://evil.com/gotcha”
The severity of the redirect flaw was far less than that suggested in initial breathless media reports because it required attackers found a susceptible application, then con users into clicking bad links and authorising permissions.
Staid Symantec staffers answered the question of whether Covert Redirect was the “next Heartbleed” with an abrupt “no”.
“Covert Redirect is a security flaw, not a vulnerability [which] takes advantage of third-party clients susceptible to an open redirect,” they wrote in a post.
“For example, an attacker could covertly issue a request to a service provider’s API using a susceptible site’s app and modify the redirect_uri parameter. The new modified redirect_uri parameter maliciously redirects users after they have successfully authenticated.”
The boffins said Covert Redirect, replete with its own website and logo, was a notable security flaw but merely sat in the shadows of the Heartbleed colossus. As OpenID Foundation board member John Bradley chimed, “allowing an attacker to specify any part of a redirect_uri will cause trouble”.
At best it served as a reminder to users to be weary of granting permissions to applications without due thought.
@migueldeicaza Web sites dumb enough to implement an open redirect have lots of security problems. Less than 1% of web, IMO.
— Danny Thorpe (@danny_thorpe) May 3, 2014
An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without any validation. If the authorization server allows the client to register only part of the redirect URI, an attacker can use an open redirector operated by the client to construct a redirect 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.
Facebook and others may have difficulty enforcing a whitelist as it may break their client deployments, but Facebook auth users can alter settings within their Facebook apps to prevent attackers from pinching their users’ IDs.
Dell’s Thorpe said some sites had legitimate reasons to implement redirects, the most common case being when users were redirected to the original page users requested. “This use of redirects should be constrained to only perform the redirect if the requested destination URL is in your site’s domain.”
Users on the other hand would be well advised to stick to the time-tested policy of verifying links and not blindly authorising permissions