Limiting the lifetime of the Request Token can also reduce the risk. In the attack scenario described an abuser must trick a user to click on the "User Authorization URL" -> this takes some time. The OAuth flow is somewhat 'instant' (I might miss some scenarios on mobile devices or devices without a browser).
Of course this does not resolves the underlying problem but might be a good practice. Correct me if I am missing something --Gilles On Tue, Apr 28, 2009 at 3:45 PM, Josh Roesslein <[email protected]> wrote: > The SP could optionally add a "buffer" to account for mistypes. Maybe allow > 2, 3, 4, etc attempts. > To the consumer it doesn't really matter how many attempts are allowed, they > can just keep trying until they > are notified the request token is no longer valid. The spec should outline > how the client will be notified when a token becomes invalid (status code, > parameter?). > > On Tue, Apr 28, 2009 at 5:21 PM, Breno de Medeiros <[email protected]> wrote: >> >> Sometimes users may hit the 'reload' button in the consumer page and that >> may result in the request token swap being sent twice. So, this implies a >> requirement on consumers to immediately redirect users to a different page >> so that the "back" and "reload" buttons won't re-submit the request. >> >> In practice, with the new changes, it would be hard for an attacker to get >> hold of the user's response within a short time frame. Since the request >> tokens are single time use already, I believe there is no reason for >> additional spec changes, though probably a discussion on a security >> considerations section of the spec (which should be moved from appendix to >> main document) may well be indicated. >> >> On Tue, Apr 28, 2009 at 3:13 PM, Leah Culver <[email protected]> >> wrote: >>> >>> Actually, I think it's a pretty small change to the spec. >>> >>> In section 6.3.2 Service Provider Grants an Access Token >>> (http://oauth.net/core/1.0/#auth_step3), it says: >>> >>> The Service Provider MUST ensure that: >>> >>> The request signature has been successfully verified. >>> The Request Token has never been exchanged for an Access Token. >>> The Request Token matches the Consumer Key. >>> >>> ... >>> If the request fails verification or is rejected for other reasons, the >>> Service Provider SHOULD respond with the appropriate response code as >>> defined in HTTP Response Codes (HTTP Response Codes). >>> >>> >>> Perhaps an updated version could say something like (changes in red): >>> >>> The Service Provider MUST ensure that: >>> >>> The request signature has been successfully verified. >>> The Request Token has never been exchanged for an Access Token. >>> There have been no prior attempts to exchange this Request Token for an >>> Access Token. >>> The Request Token matches the Consumer Key. >>> >>> ... >>> If the request fails verification or is rejected for other reasons, the >>> Service Provider SHOULD invalidate or delete the request token and respond >>> with the appropriate response code as defined in HTTP Response Codes (HTTP >>> Response Codes). >>> >>> >>> >>> >>> On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver <[email protected]> >>> wrote: >>>> >>>> Hmm... I feel like this has been lost in all the hubbub about >>>> callbacks. >>>> >>>> I strongly advocate saying something in the spec about making the >>>> token exchange (access token endpoint) one-time use only. >>>> >>>> By one-time only, I mean that the first time there is an attempt to >>>> exchange a request token for an access token, if the request token has >>>> not been authorized, then that request token should be marked as >>>> invalid. This will make a session fixation attack nearly impossible >>>> without a callback. >>>> >>>> If a service provider allows multiple attempts to exchange the request >>>> token a callback is not even necessary for the attack to work! The >>>> attacker must only keep trying to exchange the token. >>>> >>>> I know it's up to the service provider to implement one-time only >>>> token exchange, but putting it in the documentation (and libraries) >>>> will make it much easier for service providers to do the right thing. >>>> >>>> Am I missing the discussion about this? Is it on the wiki and I just >>>> can't find it? Or is everyone in agreement that this should be added >>>> to the docs? >>>> >>>> Thanks, >>>> Leah >>>> >>> >>> >>> >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
