On Thu, Apr 23, 2009 at 11:43 PM, Manish Pandit <[email protected]>wrote:
> > > > On Apr 23, 11:04 pm, Josh Fraser <[email protected]> wrote: > > Leah, > > > > > * > > > 2. No callback request parameter > > > * > > > > What if we make the callback optional? Consumers can either: > > > > a) leave it out altogether in which case the registered callback will > > be used, or > > b) include it, in which case it must be included in the signature > > I am still not sure what role the callback is playing in this (maybe > I'm too slow). Per my understanding, even if there was no callback > from the provider to the consumer, this vector would work anyway. The > identity provider has linked the request token with an identity upon > the user's post login confirmation, and any request coming in to > exchange that request token for an access token should be honored as > long as request token does not time out. This timeout too can be at 2 > levels. For instance - T1 = request token issued, T2 = request token > associated with an indentity T3 = request token used to an access > token. So the 2 timeouts can be T2-T1 and T3-T2. > > Like the folks on earlier posts noted, the timeout does not fix the > issue but reduces the window of vulnerability. I am out of ideas for > now though :( > You're right. Securing the callback doesn't eliminate the threat. It does reduce the attack vector though, and Leah's idea of only allowing a single attempt at the access token exchange reduces it further (I can't think of any reason why a consumer would attempt a request token exchange early, or multiple times). That said, a race condition vulnerability still exists, and I can imagine scenarios where an attacker could get in the middle of / sniff a transaction and have a fairly high degree of success exploiting it. I still think the only viable solution is to: 1. Ensure that the callback is not changed (this can be accomplished by specifying a callback at key provisioning, specifying the callback during the server-to-server request token exchange, or signing the redirect to the SP so that the callback can't be changed). 2. Ensure that the user who authorizes the request token is the one that completes the transaction at the consumer. The best way to accomplish this that I've seen is to generate a nonce on the SP and verify that the consumer sends the same nonce during access token exchange. The nonce would be sent to the consumer via the callback or manually via the user. As Dirk pointed out when he brought this vulnerability to the attention of this list, the attack is possible because the protocol goes over an insecure channel (the browser) and the attacker can forge a response (the redirect back to the consumer) from the authenticator (the service provider). The callback nonce would make it impossible for the attacker to forge the response without changing the callback (access token exchange would fail). And any of the three mechanisms listed above would secure the callback. That should be sufficient to eliminate the threat. Mike --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
