Authentic(ated) Maliciousness with OAuth and OpenID

A recently discovered a “Covert Redirect” weakness in the authentication processes used by the OAuth 2.0 and OpenID authentication systems can allow attackers to subvert the authentication process to drive users to malicious websites. This security flaw proves both fascinating and difficult to assess at this point.

The OAuth and OpenID technologies began with somewhat different intents, but they have now come to be used almost interchangeably. They allow end users on the Web to gain access to groups of websites through credentials hosted at one provider. In other words, they effectively provide federated authentication (single sign-on) for groups of Web properties; for example, you can use your Facebook credentials to access The Wall Street Journal or Pinterest.

OAuth and OpenID

These authentication technologies operate differently from one another, and they certainly are not direct replacements for each other. The form of this weakness largely makes these differences irrelevant, though. To simplify the language of this article, I refer to OAuth 2.0 and OpenID collectively as authorization from here on out.

The authorization “world” breaks down into three groups:

• Authorization providers
• Authorization-enabled third-party websites
• Users on the Internet

The first segment mostly includes companies like Facebook and Google, for example, that offer authorization services. The second group includes third-party websites that allow authorization through the services. The third group comprises users providing their credentials to access the websites. When an Internet user visits a third-party website, the site determines the user’s authorization based on credentials hosted by the provider. The website expects that the provider has authenticated the user — has ensured that the user is who they claim to be. For example, quite a few websites will allow you access based on your Facebook credentials, as noted above.

The Authorization Exchange

The authorization platform uses Internet redirection commands to provide this service. The basic exchange works like this:

1. An Internet user accesses an authorization-enabled third-party website.
2. The website redirects the user to an authorization provider.
3. The user convinces the authorization provider of his or her authenticity.
4. The provider redirects the user back to the original website, along with some artifact attesting to the user’s authenticity or privileges.

The weakness in this authentication process revolves around the URLs to which the provider will redirect a user after authentication. The redirection request from the website includes a field that tells the provider the URL to which the user should be redirected upon successful authentication, such as “http://example.com/check.” The Web code at that URL would check to ensure that the user authenticated properly, then dispatch them to the appropriate part of the site.

The Weakness: Security Flaw with Open Redirect

The security flaw occurs when the site embeds the destination in the request. Suppose the site fills that field with something like “http://example.com/dispatch?http://example.com/landing.html.” Suppose further that the Web code simply strips off everything up to the “?” character and redirects the user to the URL that is left, known as an open redirect. If adversaries can manipulate the contents of that URL, they can control the destinations of the redirects. This could cause a “Covert Redirect” where users to “land” anywhere with an intact authentication token. The covert redirect could take them to a server performing advertising click fraud or a repository of drive-by download attacks, or it could deliver their session variables to a token harvester. With poorly designed sites, anything could be leaked for which the user has privileges.

Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners. In another word, the Covert Redirect vulnerability exists because there is not sufficient validation of the redirected URLs that belong to the domain of the partners.

Fixing This “Covert Redirect” Security Problem

This attack requires satisfaction of two preconditions:

1. The third-party website must encode the redirect destination in the request, and the encoding must be susceptible to manipulation.
2. The third-party website must operate an open redirect.

Deny either of these preconditions and you eliminate the weakness. For most website operators, modifying the redirect Web code to perform some filtering or sanity checking on the inputs will thwart this attack. Other website operators might go so far as to redesign their redirection protocol to encode the destination differently or eliminate it from the request completely. Even after securing your site, though, you must ensure that it can’t be used to redirect to someone else’s open redirect. White lists offer an obvious choice to handle this problem; simple alternative designs work, too. For example, instead of passing a complete URL through the request arguments, a site might pass simply the path, with the redirect logic forcing the domain of the complete URL.

Impact and Conclusion

The overall impact of this weakness remains hard to assess at this point. The security weakness is undeniably present, however; the open questions include how many websites operate open redirects and how many of them use susceptible data encoding. Though each open redirect presents a verifiable risk, just how many of them are there? What percentage of the total do they represent? How much traffic do they actually process? What data can the attacker obtain with an authentication token? Until we can answer these questions, we won’t be able to assess the overall risk. Unfortunately, the answers to some will vary depending on the design and implementation of the third-party websites.

We can, however, state categorically that running an open redirect is a bad idea for your users. As these systems proliferate, the operators must add “do not operate an open authorization redirect” as part of the canon of best practices. Fortunately, it does not represent much of an additional burden on the development of the site. A bare-bones open redirect requires about five minutes to develop, a closed redirect with minimal thought requires 10. If you can’t slip that in the cracks of a development schedule, you’re not trying hard enough.