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 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 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
>> 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
>>> 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
-~--~~~~--~~--~--~---
