

Explaining the OAuth Session Fixation Attack - zain
http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-session-fixation-attack.html

======
aaronsw
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?

~~~
theRazorBlade
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.

~~~
lmea
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...

------
jsdalton
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.

~~~
theRazorBlade
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.

