On Fri, Apr 24, 2009 at 12:23 AM, Mike Malone <[email protected]> wrote:
> > > 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 don't think "race condition" is really the correct term. How would the attacker be able to get in the middle of a transaction? Pure luck? The attacker would need to call the access token endpoint with a request token that is both authorized and has not been sent to the endpoint before. Since the attacker has no way of knowing if their token is authorized or not at any point in time*, it's up to luck and is a pretty inefficient scam. * without a malicious callback > 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). Yes, I agree that these are all valid ways to ensure the callback goes to the honest consumer. Of course I prefer specifying the callback at key provisioning because it's the simplest. It's just another (optional) registration field for the consumer. > 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. I don't think this is necessary and it's a little too complex for the user. If the access token endpoint is one-try-only, I like the odds against the attacker. Leah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
