Is Your OAuth 2.0 Application Secure? - PHP OAuth API package blog

Contents

What is the Covert Redirect Vulnerability?

What OAuth Servers are Affected by this Vulnerability?

What Can You Do to Avoid this Security Attack?

Is my OAuth Application Vulnerable if it Uses the PHP OAuth API class?

Other Precautions

What is the Covert Redirect Vulnerability?

This is a security vulnerability that allows attackers to receive sensitive information obtained by redirecting users to malicious sites.

This vulnerability affects applications that implement protocols like OAuth 2.0 and OpenID. Lets see how this affects an OAuth 2.0 application.

OAuth is protocol used to access remote Web sites' APIs on behalf of users of those sites. Lets say you have a site and want to access Facebook API to obtain the name and email address of a user that accesses your site.

You can write code to implement the OAuth 2.0 protocol or use a OAuth client class like the PHP OAuth API class to implement the protocol for you.

The way it works is that your application redirects to a specific page of the Facebook site. There the user is asked if he wants to give your application permission to access Facebook API on his behalf. After the user agrees, his browser is redirected back to your site to a URL that your application specified called redirect_uri.

From then on your site completes the process to get a special access token string that will be used by your site to access Facebook API on behalf of the user. That is the access token value that will allow your application to obtain your user name and email address for instance.

Now imagine a malicious site that pretends to be your site and redirects the user to Facebook site, but instead of telling Facebook to redirect the user back to your regular OAuth authorization page, it tells Facebook to redirect the user to another page of your site that redirects users to arbitrary URLs.

This way the attacker may be able to redirect the user to his own site and get the access token. From then on the attacker can access Facebook API as if it was your application and steals your users' data.

Here is a diagram of the regular OAuth flow of the user browser when compared to the malicious flow of the Covert Redirect:

This vulnerability was discovered by Wang Jing from Singapore that created a site about the Covert Redirect Vulnerabilty and demonstrated how it works in this mute video.

What OAuth Servers are Affected by this Vulnerability?

If you got it right how it works, the problem is that in your site you may have pages that redirect users to URLs passed to those pages as URL parameters. Some sites often have those pages to redirect users to external pages, for instance to track clicks on links they have in some pages.

If you do not have such kind of pages in your site to redirect users to external sites, do not worry, this vulnerability does not affect your site.

This vulnerability could be avoided if the OAuth server would perform stricter verification of the redirect_uri by restricting it to a specific URL of the site. Many OAuth servers perform this stricter verification but some of the most popular OAuth servers just verify the redirect_uri domain.

They do not want to perform stricter verification because it would break the OAuth verification flow of many sites and cause application disruption. So do not count on OAuth servers to do their part soon.

The list of vulnerable OAuth servers is not small. Many of them are very well known and popular. Check the site above to see the list of known vulnerable OAuth servers.

What Can You Do to Avoid this Security Attack?

If you have pages that redirect users to other sites with arbitrary URLs, you can avoid this problem in three ways:

1. Get rid of the redirection pages

It would be ideal if you had no pages in your site that redirect to arbitrary external sites. If this is not possible because you still need to track external site redirection for some reason, like tracking external link clicks, this solution may not be viable for your site.

2. Use white lists validate the destination URL

Your redirection script should verify the destination URL and check if it is in the list of URLs that it is supposed to redirect. This method may not be viable if it is hard or impossible to validate all valid URLs that your site should redirect.

3. Use URL hash verification code

Your redirection page could take an additional hash parameter value. That value could be a hash of the URL combined with a secret key value that only your server knows. This way your site could still redirect to arbitrary URLs, as long as the hash verification code is correct.

The attacker could not craft an arbitrary redirection URL because he would not know your hash secret key, although he may still try to guess it using brute force methods if he knows what hashing method you are using.

Is my OAuth Application Vulnerable if it uses the PHP OAuth API class?

It does not depend on whether your application uses the PHP OAuth API client class or some other client code.

The attack is performed by redirecting the user to the OAuth server directly without going through your site authorization pages that would use the OAuth client code. When it returns the user is redirected to some other pages in your site that perform arbitrary URL redirection. Those are your site pages that you should be concerned.

Furthermore, the attack is performed when the OAuth server returns an access token appended to the redirect_uri. That happens when the client requests that the server response by of type token. That is intended more for JavaScript OAuth clients.

The OAuth API client class requests the server to send a response code. That code is used by the class to send a separate request to obtain the access token. So the access token is not obtained from the redirect URL.

Other Precautions

Unrelated to this security vulnerability, there are a couple of precautions to avoid other security problems.

1. https redirect uri

It would be better if your site OAuth redirect URL would use SSL/TLS, I mean start with https. This way your site would receive a token or a code that supposedly could not be seen by anybody sniffing the connection between your users browser and your server. Otherwise they could steal the token or code and access the OAuth server as if it was your application.

2. No Alien Javascript

It would also be better if your redirect_uri page would not have any alien JavaScript, I mean third party libraries retrieved from sites that you do not control. Otherwise those JavaScript libraries could inspect the redirect_uri to steal the OAuth token or code.

Further Questions

Security issues like this are always delicate. They require attention and full understanding of the problems to be tackled.

Admittedly the explanations above may not have been clear enough for all users that may be reading this article. If that is your case do not be ashamed to ask for further clarification.

Just post a comment to this article or look into the class code for my contact email address if you do not want to expose your situation in public.