

Details Of The New OAuth Security Vulnerability  - tptacek
http://oauth.net/advisories/2009-1

======
tptacek
"Session fixation" is an old web vulnerability. This is a very slight twist on
it.

Session fixation vulnerabilities happen when web applications (most often J2EE
applications) honor session IDs presented prior to login. After login
completes successfully, the app mistakenly recycles the session ID, instead of
generating a new one and discarding the old one.

Attackers exploit the vulnerability by creating landmine pages that coerce
users into logging in to sites with predictable session IDs (like "000000").
Once the trap is set, the attacker simply probes the vulnerable application
waiting for session "000000" to become valid.

The attack here simply substitutes "OAuth Request Token" for "Session ID".
It's otherwise almost identical.

You have a Twitter account, and use Tipjoy. You trust both Tipjoy and Twitter.
You want Tipjoy to send a message as you over Twitter. But Twitter doesn't
fully trust Tipjoy.

OAuth solves that by creating a weak relationship between Twitter and Tipjoy.
When you ask Tipjoy to act on your behalf, Tipjoy can ask Twitter for a
"Request Token", which is the moral equivalent of a session ID. Tipjoy passes
the token to you, and asks you to take it to Twitter. You present the token to
Twitter and authenticate. The Request Token is now hot; Twitter will honor it
(specifically, Twitter will allow Tipjoy to "upgrade" it to an Action Token,
which is like a logged-in session ID).

The fixation attack is simple; Alice is the good guy, Mallory is the bad guy.
Mallory gets a Tipjoy account. Mallory gets Tipjoy to give her a Twitter
request token. She then creates a landmine page that gets Alice to present the
token to Twitter. Eventually Alice (or someone like her) does. Mallory now
owns a hot token.

