Understanding the OAuth vulnerability

Last night’s OAuth Security Advisory 2009.1 was a little light on the details. The blog post wasn’t much better. I was peripherally involved in the OAuth spec development and I couldn’t work out what the advisory meant without a bunch of thinking and spec reading so I thought I’d try to explain it in simpler terms here.

For my example I’ll use the real service Twitter and a theoretical service Twitten that lets users post to to Twitter in LOL-speak and authenticates via OAuth. Alice and Bob will be my attacker and victim.

Alice’s normal authentication process goes like this:

  1. Alice loads twitten.com/login
  2. Twitten creates a regular HTTP session for Alice
  3. Twitten asks Twitter for an unauthorized token
  4. Twitten redirects Alice to an URL on the Twitter servers that will allow her to authorize the token
  5. Alice clicks OK to authorize the token
  6. Twitter redirects Alice back to Twitten
  7. Twitten exchanges its unauthorized token for an access token (associated with Alice’s account) with Twitter and stores it in Alice’s session
  8. Alice makes inane posts on Twitter via Twitten

The vulnerability here is in step 4. If instead of going to the authorization URL Alice convinces Bob to go there and authorize Twitten she can gain access to his account. Like this:

  1. Alice loads twitten.com/login
  2. Twitten creates a regular HTTP session for Alice
  3. Twitten asks Twitter for an unauthorized token
  4. Twitten tells Alice what URL to go to to authorize the token, but she doesn’t go there
  5. Alice tells Bob, “if you love Twitter and kittens try out Twitten – go to http://twitter.com/oauth/authorize/….” (the authorization URL from Twitten)
  6. Bob loads the authorization URL with his Twitter credentials and authorizes the token
  7. Twitten requests Twitter to exchange the unauthorized token for an access token (associated with Bob’s Twitter account) and stores it in Alice’s session
  8. Alice goes to twitten.com and posts “OMG PWNd” to Bob’s twitter account

I’m not really sure how to address this issue. It’s fundamentally hard to establish trust between three parties over insecure communications. Hopefully more experienced people than me will come up with clever answers.

Update: changed wording to match Eran’s suggestion, his blog post on the subject is excellent reading.

6 replies on “Understanding the OAuth vulnerability”

  1. In step 7, it is better to say:

    7. Twitten requests Twitter to exchange the unauthorized token for an access token (associated with Bob’s Twitter account) and stores it in Alice’s session

    Also, note that the attacker needs to play with callback in most cases to make it work.

  2. Ideally, the authorization page would be able to show exactly who is being authorized on the account (e.g “Twitten would like to authorize the username Alice to the Twitter account Bob), but, of course, I can’t think of a way to protect that from spoofing…. maybe a hash that’s decoded on the other end to show the username?

    I suppose this too could be spoofed with an iframe of the just the Oauth button sized to hide the text, though then the URL wouldn’t be twitten and could be another signal.

    There’s also the operation from the other side of the Oauth. After being fooled by Alic, I should be able to go to my account in Twitter and Remove the Twitten application that Alice has authorized as soon as I see that something up. Granted, she may have already done the damage.

    At the end of the day, I think it boils down to just not trusting any link to an OAuth page that isn’t coming off of the site that one wants to authorize. I would hope that everyone learned the “don’t click OK on everything” lesson by now, but I know it isn’t so.

    1. @Greg, One of the key features of OAuth is that it doesn’t know about the accounts on the Consumer side – and that’s very useful because often the Consumer won’t have an account system of its own. In my example it doesn’t make sense for a site that just allows you to post to Twitter to have its own accounts.

      One defense is for the Consumer to make sure that the session in the callback is the same as the session when the token was requested, but I think there may be some ways around that. Ultimately OAuth is better than what came before, but in itself not the solution to all of our phishing problems.

  3. Thank you for this real-world explanation. The other explanations written up around this issue tend to try men’s souls.

    You guys have thought longer about this than I have but…

    Alice’s session and Bob’s session should have some unique characteristics to them, would they not? Couldn’t some hashed value and an IP address be used to validate that the authorization URL to validate Alice is really for Alice? Bob can’t use it because we’ve locked the authorization URL just for Alice. Alice’s session has unique values in there that we are going to check for.

    As I’m thinking about it, it seems you have to trust that Twitten is going to take these kinds of measures. What about other parties that don’t? Could there be a list of approved parties that do? Ultimately, you are right, it is all about trust.

    I would use Twitten based on the fact that other people are using Twitten and have not reported problems. I would not be using Twitten just because it uses OAuth or some we-won’t-do-anything-shady-with-the-authorization-you-give-us certification. It’s their reputation. I don’t have the tools to peek under the hood to tell what they’re doing and how they’re doing it.

    So we fall back to what are the social mechanisms that we have in place that render an aura of trust around a particular company or service? What are the protocols of accountability? What are the consequences should they breach that trust?

    Hmm… it’s just as much about social practice as it is about the technology.


    1. @Rahim, thanks for your comments.

      You can’t rely on IP addresses to ensure identity. I’m actually mostly likely to want to carry out this kind of attack against my coworkers who’re sitting behind the same IP as me in my office right now 🙂 You can’t rely on sessions on the Consumer (ie: Twitten) side of things because Bob may never reach that page. As Eran said you can manipulate the callback URL as part of the attack to prevent Bob from ever seeing a genuine twitten.com page.

      Until we come up with approaches to prevent this it’s not about knowing which applications are safe because none of them really are.

Comments are closed.