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 <leah.cul...@gmail.com> 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)<http://oauth.net/core/1.0/#http_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) <http://oauth.net/core/1.0/#http_codes>. > > > > > On Tue, Apr 28, 2009 at 3:02 PM, Leah Culver <leah.cul...@gmail.com>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 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 -~----------~----~----~----~------~----~------~--~---
