Twitter’s OAuth problem turned out to be a general problem affecting other OAuth service providers and well as consumers using ’3-legged’ OAuth use-case. For details, you should read not only the relevant advisory but Eran Hammer-Lahav’s post Explaining the OAuth Session Fixation Attack.
First hint of the vulnerability surfaced last November as a CSRF-attack at Clickset Social Blog which was initially diagnosed as an implementation-level issue. Well, it turned out to be a design flaw requiring some changes to the protocol.
There are actually two flaws.
The first flaw is that parameters of HTTP redirects used in OAuth can be tempered with or replayed.
This flaw allows hackers to capture, replay, and mediate conversations between OAuth Consumer and Service Provider flowing over the surface of User’s browser between the User, Consumer, Service Provider.
I think the easiest general remedy for this flaw is including a hash of the HTTP redirect parameters and some shared secret like consumer secret. A more general solution like evolving tokens could be done as well but inappropriate as a quick remedy.
This flaw should not affect OAuth service providers that manage and monitor callback URLs rigorously.
The second and more serious flaw is that the User talking to the Consumer may *not* be the same User talking to the Service Provider.
This means that a hacker can start a session with TwitsGalore.com then phish someone to authorize at Twitter to gain access to TwitsGalore.com as that someone without stealing password or session-jacking.
Solving the first flaw simplifies the solution to the second flaw by reducing the possibility of the hacker intercepting callback from Service Provider to Consumer which is not supposed to have any sensitive information but some implementations might include. Wire sniffing is a concern if HTTPS is not used but the relevant concerns for the flaw are integrity and identity, not secrecy which is an application factor.
Removing the possibility of callback URL tempering leaves double callback, meaning that the hacker start things off, tricks someone into authorizing without intercepting the callback, then simulate a callback to Consumer. Note that the Consumer would have started a HTTP session with the hacker, session associated with the RequestToken in the callback. Even if HTTP session is not created until the callback is received, there is no way for the Consumer to tell who is who.
I think Service Provider have to send back a verifiable token, like a hash of the RequestToken and consumer secret so the hacker can’t simulate the callback.
Regardless of which solutions OAuth guys decide on, one thing is clear. It will take time, many weeks at least, if not months. That’s going to put quite a damper on developers in the Consumer side of the OAuth as well as the Service Provider side.
