Ah, open standards. They’re fabulous, aren’t they? Take OAuth for instance. Idealism and interoperability! What’s the gist behind OAuth? Well…
Imagine you’ve got a service that allows you to, say, microblog your life. Then you’ve got another service that allows you to post and share photos on the Internet. You want to make these two services work together — when you upload a new image, the photo sharing service should update the microblogging service to notify your friends about it. Now, maybe the photo sharing service wants your microblog credentials, but you don’t want to give them up. Ah, but it turns out both services support OAuth! So, you tell the photo sharing service about your microblogging service, the microblogging service asks you if you want to grant the photo sharing service access, they exchange some information, and voila: the photo sharing service can notify your friends about your uploads without ever knowing your password!
This concept is so simple, so effective that it makes sense for it to eventually catch on. Sure, OAuth popped up here and there, but what seems to have pushed it into the mainstream was its adoption by Twitter. As a public beta, Twitter recently started supporting OAuth in their service, a well received move. But on the morning of April 22, Twitter unexpectedly pulled the plug on the protocol, as noted by TechCrunch; a comment on the TechCrunch story noted that Yahoo’s OAuth support had been yanked, too. One TechCrunch reader noted that it “sounds like there’s some massive security hole they’re busily patching up.”
It wasn’t but a few hours later when CNET broke the news that the real issue was, indeed, security-related:
A security hole in OAuth, the open-source protocol that acts as a “valet key” for users’ login information, has led services like Twitter and Yahoo to temporarily pull their support, CNET News has learned…. In the interest of online safety, CNET News has chosen not to make the details of the security hole public. Here are the basics: The hole makes it possible for a hacker to use social engineering tactics to trick users into exposing their data.
Twitter even issued an official stance on the whole debacle over at their blog:
This week, we received word from the folks at OAuth that they were looking closely at a security issue within the protocol. We take security seriously and felt the responsible thing to do was temporarily disable OAuth while this matter was sorted out. Yahoo and others made similar decisions.
“Yes, yes, that’s all well and good, you waffle-faced bastard, but what’s the issue?!” Well, it all comes down to a token, of course. Per the OAuth advisory*, released on Thursday, April 23 at 03:00 AM EDT (12:00 AM PDT), there exists a nasty, but obvious-in-the-way-the-spec-is-written-good-deity-how-did-this-get-overlooked, session fixation vulnerability:
The attack starts with the attacker logging into an account he owns at the (honest) Consumer site. The attacker initiates the OAuth authorization process but rather than follow the redirect from the Consumer to obtain authorization, the attacker instead saves the authorization request URI (which includes the Request Token). Later, the attacker convinces a victim to click on a link consisting of the authorization request URI to approve access to the victim’s Protected Resources to the (honest) Consumer.
By clicking on the link, the victim continues the request that the attacker initiated, including the Request Token that the (honest) Consumer issued to the attacker. Note that the victim is redirected to the legitimate approval page at the Service Provider and prompted by the Service Provider to approve the (honest) Consumer. It is not possible for the victim to detect that there is an ongoing attack.
After the victim grants approval, the attacker can use the saved Request Token to complete the authorization flow, and access whatever Protected Resources are exposed by the (honest) Consumer site as part of its service.
XSRF protections at the Consumer site do not mitigate against this attack.
(Update 2009-04-23 06:33) — The OAuth advisory also points to a more detailed analysis of the attack over at Hueniverse. I recommend reading this as well.
As someone who advocates open standards such as OAuth and OpenID, which are oftentimes used as complements to one another, it pains me to see such a nasty flaw rear its head — especially right after it seemed to be getting some traction. A revised OAuth specification is forthcoming that should address this issue.
* – please note that we honoured the timeframe set forth by OAuth by publishing this post only when the officialy advisory had been released. (And no, we did not discover this flaw. We merely had, uh, accurate discussion and speculation around it.)