The most amazing thing about this is that it took them so long to think of this attack. It's a pretty simple idea. Is it really possible that so many major companies implemented this spec without even thinking it through?
Everyone is asking themselves the same question. Parts of this attack were identified last year but the full scale was not appreciated by the people who identified some of the issues. Everyone assumed that good security practices will be enough. So yes, everyone just missed it, and probably would continue to miss it if it wasn't for some unique situation last week which I will share soon.
I'm wondering if the novel usage of OAuth for single click login to twitter might have played a role in letting the vulnerability emerge, as in that case it seems a lot easier to trick someone to click on an OAuth-related link on some site different from the consumer.
Looking at the protocol while thinking to the basic use case (authorizing API access to some consumer app) one tends to think that tricking a user to start the authorization step from outside the consumer could not be easy. But in this flow: http://apiwiki.twitter.com/Sign-in-with-Twitter the case 3 (user logged in to twitter) is really similar to the attack case, except that in attack the request would be to oauth/authorize instead of to oauth/authenticate...
For what it's worth (not much), a few months ago I did my own quick, amateur analysis of the OAuth security. I suspect it's more of the case that it's easy to get stuck looking at the raw protocol itself for vulnerabilities to see how best to avoid allowing people to spoof the communication, get data they shouldn't get, etc. Those seem the riskiest areas in the whole process and where you'd find the weakest links.
So while they focused on protecting the information assets that OAuth shuffled around, they overlooked using the URLs in the middle as a way to fool the requesting app itself. It's one of those design-level flaws that are difficult to see until you've gotten past full analysis of the other high-risk portions of the OAuth chain.
We had someone on the team looking at it, but our emphasis was on things that a consumer or service provider stack could screw up in software, not so much on the protocol itself. (Our analysis was also very, very casual; we wrote code for it, but we didn't have a project plan.)
The other thing that messes with you with OAuth is how closely OAuth resembles a lot of ad-hoc schemes that preceded it; many of them have been tested and analyzed to death, so it lulls you into a false sense of confidence.
Please feel free to point out if I'm wrong on this, but I don't quite understand why this cannot be solved by stiffening up some of the requirements for the callback portion of the authorization sequence.
For instance, the Provider could return two tokens with the callback: the original request token (to identify which request the callback is for) and a second "callback" token. To obtain an access token, the consumer would have to provide both the original access token as well as the callback token. Since the callback is issued as a redirect to the user, it wouldn't be possible for an outsider to discover the value of that callback token (I don't think?).
To provide additional security, I would think you could drop the request token from the callback URL altogether, and force the consumer to save the request token in a user session or cookie.
Well, I'm sure it's not as simple as this but I'd be interested in hearing why not, if that's the case.
If you read the end of the article, it suggests a similar idea of adding something to the callback on return that the attacker cannot guess. However, this requires a protocol change which both providers and consumers have to implement and is not something we can roll out overnight. It requires a new version of the protocol.
