On Thu, Apr 23, 2009 at 7:11 AM, Luca Mearelli <luca.meare...@gmail.com>wrote:
> > first of all, my sincere thanks to all those involved in this for how > it has been managed! > > Since reading the advisory and the post an Eran's blog, I kept > ruminating about the issue, here are a few thoughts: > > To solve the problem we'd need a way to make it impossible (or at > least very hard) for the attacker to get an access token from the > request token authorized by the real service provider user. > > Since the attacker knows the request token (he has generated it) we > need some information to be passed around that the service might use > to verify that the request token is being exchanged with the access > token by the same user that authorized it. > > It could be some token (or signature) that the service provider > generates before sending the user back to the consumer to complete the > request and that should be passed to the service provider upon token > exchange. I guess that this is more or less what Eran said in the > blog: "an unpredictable callback parameter generated at the Service > Provider to the callback URI on return". > > But if we do so we also need to make sure that the callback URL is NOT > taken from the parameters passed in the redirect to the service > provider that the user follows when authorizing (step 6.2.1 of the > spec) or at least that it is "vetted" (allowing only those within a > specific domain). Allowing callbacks only within a specific domain is not a sufficient security mechanism for most web sites. It assumes that the website does not have any URL which is an open redirector, as you mention below. > > If the Service provider accepts any redirect then any information that > it want to pass back to the consumer might be intercepted by the > attacker (via a callback that goes through an attacker controller > host). It also assumes that the site does not provide interfaces for the attacker to create image links that can cause leakage of the parameter via referer header. > > Another option to make sure the SP can pass information to the > consumer would be to add the oauth_callback parameter to the request > token request (step 6.1.1) and use that callback when the request > token is exchanged for the access token (this parameter should be > generated by the consumer site and not know to the user or the > attacker until the redirect). I believe this would be a much more robust way to protect the secrecy of any oauth_callback parameter. > > > A last thing that might mitigate social engineering attacks could be > to require the consumer to pass to the service provider some > information about who their user who is requesting the request token > is, then the service provider could show this infos to the user trying > to authorize the request token (e.g. the SP may say: "you are going to > authorize the user Xyz at the service Abc access to your data"). > > what do you think? > > ...just my 2c > Luca > > > > -- Breno de Medeiros --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
