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.)
From the BBC:
The first big steps on the road to overhauling the net’s core addressing system have been taken.
On Monday the master address books for the net are being updated to include records prepared in a new format known as IP version 6.
Widespread use of this format will end the shortage of addresses that sites can be given.
The net’s current addressing scheme is expected to exhaust the pool of unallocated addresses by 2011.
Read on.
Tags: Net Addresses, Internet Addressing
Well, unlike our American brothers to the south we here in Canada have Tax deadline looming for April 30th. Normally we (my house) file earlier but, this year life pushed us back.
Today we sat down and worked our way through our tax return in a few short hours. The QuickTax software is actually quite good and keeps me from mounting a bell tower and picking off the neighbours. Kidding of course but, the software is normally not too bad. That is, until I clicked the final button. I was presented with this:
AUGH!
I’m having one of those days. Now, without shedding any light on my position what would the security community do when designing a web portal? There are multiple vendors out there that provide solutions such as Sun, IBM (Websphere), Microsoft et cetera. But, the part that I would really like to get some feedback on is, would you use:
- one portal to unify internal and external apps
- one portal for internal apps, one for external apps
- or a portal based per function?
I would love to hear some thoughts on this one. Please leave a comment or drop me a line via email.
Thanks in advance for your time.
Tags: Portal, Security Architecture, Security Design
