An update on the OAuth session fixation vulnerability

While the merits of several solutions to the OAuth session fixation vulnerability are still being hashed out on the wiki, I wanted to share the latest episode of theSocialWeb.tv, captured yesterday on location at Google’s headquarters in Mountain View, providing some background and technical details about the problem, as told by Eran Hammer-Lahav, who has been coordinating the community’s response.

Marshall Kirkpatrick of ReadWriteWeb also has a great write-up of the timeline of events that lead to the discovery of the issue, shedding more light on how quickly the community mobilized to confront this threat.

About this entry

You’re currently reading “An update on the OAuth session fixation vulnerability,” an entry on OAuth

Published:: April 25, 2009 / 6:50 pm

Category:: security

Tags:: eran hammer-lahav, thesocialweb.tv

Good informative video guys.

However, for us, we think the advisory is probably a bit over alarming.

While a token session length is useful, a determined hacker could just generate a fresh token each time they send a user into their trap.

This problem only affects apps where the evil user has an account with the consumer, i.e., a consumer user accounts gathers additional data from a provider.

Apps where a consumer user account is created along with info provided are not affected, i.e., the app uses the token as a user ID, hence no evil user could get this without having the approved token.

I think the easiest way to implement a fix if for consumers to sign a callback url in the token request, so evil.com doesn’t get the token given back to them. (This way the providers don’t have to bother registering/storing/validating various callback URLs (I would want more than 1), and I don’t have to think about notifying providers if I make any changes to my callback URL either).

Another option, as this problem only affects existing user accounts on good.com, is for good.com to also sign and pass over the username for the requesting account.

The provider displays “Hello Bob, The user ‘bob2009′ at http://www.good.com wants to access your address book, is this OK?”

Ideally, I’d have both username and callback urls signed and passed over. Though it looks like from the Wiki you have it under wraps.

The sooner you agree, the sooner Google will remove that horrendous “this application is not configured securely” warning when the user approves, set as per your advisory.

OAuth

An update on the OAuth session fixation vulnerability

About this entry

1 Comment

Have your say

Blogroll

Categories

Archives