The Authorization Code Redirect URI Manipulation attack in OAuth 2.0

Changing the authorization code redirect URI is one of the ways by which attackers try to game the OAuth 2.0 authorization framework. This article discusses how this attack works in detail and how this attack can be prevented.

If you are not sure of how OAuth 2.0 works, it is better to get an understanding of it here.

OAuth 2.0 makes use of browser redirection to take a user from the webpage of an authorization provider back to the client that the user is trying to authorize. To begin with, the client sends the redirect URI as a query parameter when redirecting users to the authorization provider’s website.

Once the user authenticates himself and authorizes the client to access his data, the authorization server redirects the user back to the client’s site with the authorization code using this redirect URI. However, this attack works by modifying the redirect URI that the client sends as a query parameter to the authorization provider’s site.

The redirect URI

As you may know, to access a protected resource of a user, client applications should have registered themselves with the authorization server and obtained their client credentials such as a client ID and secret.

Let’s assume that a photo editing web application called Photo Editor that runs on www.photoeditor.com wants to allow its users to access their Facebook photos and edit them on their app. First, Photo Editor would register itself with Facebook and obtain a client ID and client secret.

Then, the client needs to have a button or a link to allow users to authorize the application accessing their Facebook photos. So, Photo Editor would create a link to the authorization provider and append its client ID, the grant type, and the redirect URI as query parameters.

This URI would be the link to which the authorization server redirects the user once authorization is complete. The authorization server would append the authorization code as a query parameter to this URI. Let’s say it is http://www.photoeditor.com/auth.

First, a user would create an account with Photo Editor. Then, he would click on this link to authorize the application accessing their Facebook photos. Then, the user agent takes the user to Facebook where they can log in and authorize access.

This is how this flow would work usually. However, an attacker can modify this link to get access to an unsuspecting user’s Facebook account. Let’s see how this attack works.

How does it work?

Initially, an attacker would create an account for himself at Photo Editor. Then, the attacker would copy the link generated by the app and insert a rogue redirect URI instead of the redirect URI pointing to Photo Editor. Let’s say, it is http://www.attacker.com/auth.

Then, the attacker can make a victim click on this link and authorize Photo Editor accessing their Facebook photos. However, this may require social engineering.

Once the victim authorizes Photo Editor, the victim is redirected to the attacker’s URI with the authorization code. Then, the attacker can receive the authorization code at http://www.attacker.com/auth. Next, the attacker would append his authorization code to the Photo Editor’s redirect URI (http://www.photoeditor.com/auth) and send a request to Photo Editor. Subsequently, Photo Editor would use this authorization code to request an access token from Facebook to access the victim’s Facebook photos.

Once Photo Editor receives the access token, the attacker can, then, access the victim’s Facebook photos through his account at Photo Editor.

It is worth noting that, here, an attacker is hijacking the usual OAuth 2.0 authorization grant flow by redirecting the victim to a rogue endpoint, obtaining his authorization code, and sending the authorization code to the actual endpoint.

How can this attack be prevented?

This attack can be prevented by employing two security checks. First, by requiring a client to specify a redirect URI at the time of registration and ensuring that the redirect URI sent along with a request to obtain the authorization code is same the as the registered redirect URI.

For example, if Photo Editor specifies http://www.photoeditor.com/auth as the redirect URI when registering their application with Facebook, Facebook will not grant the authorization code if the redirect URI sent with the request is http://www.atatcker.com/auth.

After that, authorization servers can check if the redirect URI used to obtain the authorization grant is as same as the redirect URI used to obtain the access token. If you take our example, the authorization grant is obtained using http://www.attacker.com/auth, and the access token is obtained by Photo Editor using its own URI. If this check is implemented, then Photo Editor won’t be able to obtain the access token, consequently, preventing the attacker from accessing the victim’s photos.

Most OAuth providers implement the aforementioned security checks and this form of attack is very rare.