Covert OAuth Redirects and Perverse Incentives

Published June 3, 2014 | By Dan Blum

Covert redirect is a structural vulnerability in OAuth-based protocols. It was widely publicized in early May. Identity and security experts had long known about, but don’t have an easy fix. Once the media learned covert redirect isn’t as serious as Heartbleed, the stories died down and it went back to the status quo: benign neglect. Why? Facebook, Google and other service providers have a perverse incentive to sign up droves of third party affiliate web sites regardless of whether they’re vulnerable or not.

Danny Thorpe’s blog post provides a pretty good explanation of how covert redirect can be exploited. “Here it is in a nutshell: If [the application] web site (example.com) implements an open redirect endpoint – that is, implements a URL that will redirect the browser to any URL given in the URL parameters – AND your redirect copies URL parameters from the incoming URL to the outgoing redirect URL, then it is possible for third parties to exploit this artifact of your web site in a wide variety of nasty ways.”

Note that the “application web site” in this example is the one that needs access to your resource controlled by the OAuth authorization server. For example, the Angry Birds application might be requesting access to some of your Facebook information. The covert redirect bug is technically an “unvalidated redirect” per OWASP. It is one of the top 10 web applications vulnerabilities OWASP found in 2013.

Covert redirect arises from thousands of third party application web sites that don’t check their URL parameters during the OAuth ping pong dance. It’s not a bug in the code of service providers like Facebook, Google, LinkedIn – but they are nonetheless the targets. Although hackers actually exploit the third party application what they’re after are the OAuth access tokens to resources on the big service provider sites where users “live.”

It’s the Big WONTFIX. Facebook, Google, LinkedIn and others can’t patch it because it’s a bug on third party sites. To fix it would require strict pre-registration and whitelisting of those sites. That would stifle traffic and since traffic generates advertising revenue and other fees, that would be bad for business. And because these service providers are also social login providers, this is a matter of concern. It should not be dismissed just because there isn’t a quick patch.

While we’re on the subject of “perverse incentives” and what’s good for business, you’ll find the golden rabbit hole goes deep indeed. The technical problems with OAuth that I wrote about in REST Uneasy and other OAuth 2.0 Assurance Issues arise from fast and loose practices with user’s personal data and privacy. A weak protocol meets risk aggregation and perverse incentives. There may be an even bigger story here. Unfortunately, it seems the big service providers may be equally loose on fraud, when it comes to their advertising bottom lines. See the sequel to this post: Dark Lords of the Internet.

Another follow-up post I may do concerns new specifications that the OAuth standards community are developing for dynamic registration. I want to analyze whether dynamic registration will make the covert redirect problem better, worse, or if its even related. Whether there’s even any hope for OAuth or OAuth-based protocols becoming more secure.

Recommendations for users: Don’t use social login and minimize granting of permissions across sites. Don’t reuse passwords on multiple sites or use weak passwords. Don’t wait for FIDO or Google to come up with a convenient solution, just get a password management tool. Use easy two factor authentication solutions wherever possible, and generally be alert and mindful out there.

Recommendations for developers: Don’t enable open redirect. Validate any redirect URLs to make sure they stay on your site, or in your white lists. Update your software development lifecycle (SDLC) guidance to address covert redirect and other OWASP issues.

Recommendations for service providers: You have no business as an identity or security provider unless you too, take your medicine. Develop security guidelines for third party applications you consort with through OAuth. Create a whitelist. For higher risk applications, certify or test the third parties yourself before they can get on the white list. For lower risk applications, require that third parties self-assess and certify to you that they are free of the vulnerabilities specified in your guidance before putting them on the whitelist.

Recommendations for enterprises: Similarly to service providers, create security guidance and requirements for partners. Assess developers and service providers against whether they are following those guidelines and don’t pay them unless they do so.

Covert OAuth Redirects and Perverse Incentives

Subscribe to Blog Notifications... HERE