I think was a little unclear in my statement regarding the Consumers' duties. Allow me to rephrase:
As a consumer you need to do one of two things: 1) Mixed Binding - Ensure the user who initiated the dance is the one who completed it and then associate the access token/secret with that user. 2) Late Binding - Only rely on the identity of the user who completed the dance and associated the access token/secret with that user. What you've described is 'Early Binding' and generally a bad idea for the very reason called out. Darren On Sat, May 9, 2009 at 12:04 AM, Darren Bounds <dar...@cliqset.com> wrote: > 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 <pandit.man...@gmail.com> 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 > dar...@cliqset.com > -- darren bounds dar...@cliqset.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
