Cliqset Social Blog

The OAuth Protocol

For those of you who aren’t familiar with it, OAuth is a relatively new (1.0 is less than a year old) protocol designed to help provide a simple, secure authorization scheme for web and desktop applications. It’s particularly useful as a mechanism for users to authorize access to resources in one application (like a friends list) to be consumed and potentially manipulated by another; all without requiring the user to divulge their authentication information.

OAuth Authentication Flow Diagram (see: http://oauth.net for additional information)

Cross Site Request Forgery

Cross Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has for a particular user.

CSRF attacks work like this:

An attacker embeds an object or script within a document (typically a web page) that links to a resource within a web application the victim is (or is supposed to be) authenticated to. When the page is rendered, the victims web browser makes a request for that resource in the context of that users authenticated session and executes whatever application functionality that particular resource was intended to perform.

Take the following trivial example:

<img src="http://app.com/new-passwd?newpass=h4ck3d" />

Hopefully when you see that you think two things:

1. I enforce password change functionality in a POST request.
2. I require the user enter their current password when setting a new one.

If not, your password change functionality is likely vulnerable to CSRF.

OAuth and CSRF

Remembering the OAuth Authentication Flow Diagram we saw earlier, the following is a fairly common OAuth use case:

SocialMesh (Service Provider) – An imaginary traditional social network that supports OAuth access to social information.
MySocialFeed (Consumer) – An imaginary social information aggregator that uses OAuth to gain access to social information on other websites (e.g. SocialMesh).

1. John registers with MySocialFeed.
2. MySocialFeed asks SocialMesh for a Request Token.
3. After receiving it, MySocialFeed redirects John to SocialMesh with the Request Token in the URL.
4. If John is already authenticated to SocialMesh, he is prompted to authorize access by clicking a link.
5. After clicking the link John is redirected back to MySocialFeed.
6. MySocialFeed exchanges the approved Request Token for an Access Token.
7. MySocialFeed now has access to John’s social information on SocialMesh.

Now imagine a slightly altered scenario. This one involves an Attacker who’s interested in gaining access to John’s super valuable friends list!

1. Attacker registers with MySocialFeed.
2. MySocialFeed asks SocialMesh for a Request Token.
3. After receiving it, MySocialFeed attempts to redirect the Attacker to SocialMesh with the Request Token in the URL.
4. The Attacker traps the request and extracts the Request Token.
5. The Attacker embeds an IMG tag in a webpage that links to the OAuth authorization page at SocialMesh and sends a phishing message to John via SocialMesh.
6. John logs into SocialMesh, reads his messages and clicks the unassuming link.
7. The webpage renders and initiates a request to SocialMesh authorizing the Attackers Request Token.
8. MySocialFeed exchanges the approved Request Token for an Access Token.
9. MySocialFeed now has access to John’s social information on SocialMesh for the Attacker to use as he/she likes.

This example exploits what I feel will be a very common OAuth authorization implementation. The Service Provider passes the pending Request Token from the authentication page to the authorization approval page. The user then authorizes the Request Token through a simple GET request.

Conclusion

As useful as OAuth is, it is an authorization protocol and extra care should be taken to ensure it is implemented properly. As OAuth becomes increasingly mainstream (it was recently implemented by NetFlix (http://developer.netflix.com/docs/Security#jcs-3)) the value in attacking services that leverage it will go up.

Make sure your OAuth authorization page is CSRF safe!

Recommended reading:

http://www.owasp.org/index.php/CSRF
http://jeremiahgrossman.blogspot.com/2006/09/csrf-sleeping-giant.html
http://en.wikipedia.org/wiki/Cross-site_request_forgery