Manish, See my post and subsequent thread from last week which I believe is what you're describing:
http://groups.google.com/group/oauth/browse_thread/thread/1c3874d94008135a/a99aaa5de87f98dc As a consumer you need to ensure that the user who *completes* the negotiation is the same user who authorized the access token at the SP. The initiating user is somewhat irrelevant. Additionally, Brian Eaton and I have submitted the following language relating to CSRF attacks which draws attention to this form of attack. http://groups.google.com/group/oauth/msg/f02d7d2bf10bad36 Darren On Fri, May 8, 2009 at 9:50 PM, Manish Pandit <[email protected]> wrote: > > There you go again: > > Assumptions: > > 1. The provider requires a callback_url with get_request_token, signed > per the 1.0a. > 2. The provider returns an oauth_verifier along the blessed request > token on the callback (if not oob) to the consumer upon user consent. > 3. The consumer has a database table (or any other mechanism) to store > a user identifier (user's identity at the consumer), request token and > access token > 4. The provider has a database table (or any other mechanism) to store > the user identifier (user's identity at the provider), request token > and access token > 5. The endpoints are one time use only - so authorize_token and > get_access_token can be called once and only once for a given token. > 6. The victim consents to providing access to the consumer for his > protected data. > 7. The access token lives long enough for these steps (usually a few > hours) > 8. The request token lives long enough for steps 3 though 11. > > Flow: > > 1. Evil user (identity = eviluser) logs in to the consumer webapp. > > 2. Clicks a link to access protected resources on the provider > > 3. Consumer gets a request token per 1.0a (token1), and redirects the > eviluser to provider's login page. > > 4. Consumer record says {userId=evilUser, requestToken=token1, > accessToken=null} > > 5. Provider record says {userId = null, requestToken=token1, > accessToken = null} > > 6. eviluser copy-pastes this link and sends it to the soon-to-be > victim via IM to get everything done in the request token TTL which > can be few minutes. Evil user does not even need to be online after > this step. > > 7. The soon-to-be victim get the IM, clicks on the link. > > 8. Everything checks out, the victim logs in to the provider with his > credentials (gooduser). The provider updates the record at their end. > > 9. Provider record now says {userId=gooduser, requestToken=token1, > accessToken=null} > > 10. Provider now generates an oauth_verifier (abcd). Appends it to > oauth_token=token1 and calls back the consumer on the callback > provider in step 3 > > 11. The consumer gets the callback with the token and verifier. The > record still says {userId=eviluser, requestToken=token1, > accessToken=null} > > 12. The consumer tries to convert this token to access token, now that > it has received the callback with a verifier. It may or may not store > the oauth_verifier. (In my provider implementation, I am not storing > the verifier and relying completely on the signature verification) > > 13. The consumer per 12 creates a signed request (including the > verifier) to request access token against the blessed request token. > > 14. The provider gets the request, and converts the requestToken to > access token as everything seems to be alright. The provider record > now says {userId=gooduser, requestToken=token1, accessToken=token2) > > 15. The provider returns the accesstoken to the consumer. Consumer > record now says {userId=evilUser, requestToken=token1, > accessToken=token2). > > 16. Now eviluser logs in to consumer, accesses a protected endpoint > (getAddressBook.do). Since the consumer already has an access token > for evilUser (see the db record above), it sends the request to access > protected resources. > > 17. The provider looks up the user who has that access token > (gooduser, see db record above) and returns gooduser's addressbook to > the consumer. > > 18. The consumer passes along the gooduser's addressbook to the > eviluser. > > There you have it - I really really hope I am missing something here. > > Since the spec does not have any guidelines for the consumer (it > should never do anyway), we cannot assume that the consumer is or is > not linking identities and tokens in a particular fashion. Besides I > think the whole scenario can be replicated without the record at the > consumer too, but Friday 6:45P I am too fried to think further :( > > -cheers, > Manish > > > -- darren bounds [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
