On Apr 23, 10:50 am, Paul Lindner <lind...@inuus.com> wrote:
> Hi Luca,
>
> In the past few days we have discussed some of the options you mention
> below. I even created some prototypes for the 3-legged OAuth
> implementation in shindig to test them out. Note that these
> proposals only mitigate the problem, they do not solve it. They do
> add useful features and I hope that we can discuss their merits and
> either add them as extensions or incorporate them into the base
> protocol.
>
> -----
>
> I have two changes to the protocol, the first, which has been
> previously mentioned, I propose be named "Strong Callbacks." To
> implement strong callbacks the consumer must send an oauth_callback
> parameter when obtaining a request token.
>
> The provider can then take the following actions:
>
> 1. callback URL specified for request token, callback URL specified
> for authorization
>
> FAIL the request and send email to the security team. A third party
> is trying to inject a callback URL.
>
> 2. callback URL not specified for request token, is specified for
> authorization
>
> Equivalent to existing OAuth protocol
>
> Generate "scary warning" for the user that the consumer wants to
> redirect, but don't actually do it. Display the URL and help the user
> choose whether they want to redirect or not.
>
> This does not solve the problem, it only mitigates it somewhat. If a
> consumer uses predictable callback URLs then the attacker can still
> carry out the attack, it's just more difficult -- the attacker may
> have to set up a proxy to the authorization flow so they can intercept
> the browser->service provider flow or hit the URL with proper timing.
>
> -----
> Proposal number two I call "Tight User Binding".
>
> One issue with OAuth is that you are defacto granting access to your
> account to an entire consumer key, which is generally an entire web
> site or client. If a provider caches this authorization and
> automatically redirects to a callback URL then an attacker can gain
> access without the end user even knowing about it. (see the flowchart
> at twitter to understand how this can be dangerous:
> http://apiwiki.twitter.com/Sign-in-with-Twitter)
>
I think this is exactly right -- access is to entire consumer key (not
so good). But one needn't go so far as "identifying" the user, rather
the provider needs a way to confirm that the initial request (A) can
be tied to the "authorize token" request (C) -- by connecting it to
user (even if this "user" only exists for this one transaction -- thus
my thought of a PIN), or by some other means such as a "challenge."
It'd be nice to add it into the consumer secret (and include
combunation in URL) so the provider need not maintain state between
requests. Seems like the two options are for the user to self-
identify (e.g., PIN, an "is this you?" prompt, etc.) upon
authorization request OR have the provider maintain state between A &
C.
--peter
> Instead of this blanket authorization we want to grant access to a
> specific USER/CONSUMER combination. For an analogy look at the
> mysql grant command. The current OAuth authorization pattern is
> similar to this:
>
> GRANT ALL ON localuser.* TO ''@'remoteconsumer';
>
> You grant access to a consumer, not to a consumer/user pair. Instead
> we want the equivalent of this:
>
> GRANT ALL ON localuser.* TO 'remoteuser'@'remoteconsumer'
>
> Remote user may mean different things depending on the consumer. For
> web sites this could be a profile URL which, when fetched reveals the
> users name/thumbnail url etc. I suggest leveraging microformats and/
> or link rel tags. Sites without the concept of a user may have to use
> some other identifier.
>
> For mobile or desktop clients, things are less clear. Perhaps simple
> user identifiable information is sufficient. A delegated identity
> might be required.
>
> To pass this information a consumer can send the identifying
> information via an 'oauth_initiating_user' parameter when obtaining a
> request token.
>
> In either case we now have remote user information *and* consumer
> information. The authorization screen will include this information,
> along with a "That's not Me!" button.
>
> This doesn't stop all lines of attack -- an attacker could set up
> cloned profiles that "look" like the remote user and attempt to get
> the user to authorize.
>
> There's also a privacy issue. Perhaps the user does not want to share
> identifying information with the consumer. However... As a provider
> I'm very interested in binding accounts in the reverse direction,
> especially partners where I have a bilateral agreement in place.
> (Again, this might not be something that end-user desires...)
>
> On Apr 23, 2009, at 7:11 AM, Luca Mearelli 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).
> > 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).
> > 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).
>
> > 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
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
