You are putting too much weight on the value of redirection URI
registration. Since the same problem exists between the user-agent
script and the server-side component used in the user-agent profile,
anyone can imitate that flow. In most cases, the redirection URI will
simply include a script that will pass the parameter to the **parent**
window which can be anything. If the server-based page is an active
page, it still needs to communicate with the user-agent, which again,
can pretend to be that.
As long as the access token is passed back to the user-agent
application, you can imitate it and pretend to be another client.
EHL
*From:* Andrew Arnott [mailto:andrewarn...@gmail.com]
*Sent:* Friday, July 02, 2010 7:24 PM
*To:* Eran Hammer-Lahav
*Cc:* Ian McKellar; Marius Scurtescu; OAuth WG (oauth@ietf.org)
*Subject:* Re: [OAUTH-WG] Security of user agent clients (WAS: End
user auth response code-and-token's scope parameter)
I agree with the installed client issue it cannot be solved. But for
a browser-based user-agent script, it's particularly dangerous to not
solve it, and I believe it can be solved. By forbidding unregistered
redirect_uri values to be included in the request for a direct access
token, user agent scripts can't (as far as I can imagine) productively
spoof other clients. That is, they could pretend to be the popular
client that is already authorized to get another access token, but the
token would be sent to the real client via redirect and not be
accessible to the evil client.
And it's the web-based client that I am most concerned about. An
installed client already has some degree of trust with the user since
it is software running on the OS. But any and every web site the user
visits could crack your Facebook account (or any other OAuth-enabled
resource server) simply by formulating the request with a client_id
that has likely already been authorized in a hidden iframe.
I see this as a /real /problem, and I'm proposing what I believe is a
working solution. Again, I'm /not trying/ to solve the installed
client problem and I think that's much less severe anyway. But the
web-based one must be solved, and this is a way to solve it IMO.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the
death your right to say it." - S. G. Tallentyre
On Fri, Jul 2, 2010 at 2:13 PM, Eran Hammer-Lahav <e...@hueniverse.com
<mailto:e...@hueniverse.com>> wrote:
There is nothing you can do to protect any non-server-based client
from imitating another client. All you can do is require the end-use
to be present when you cannot trust who the client is (assuming you
trust the user to know what they are doing). What providers need to do
is understand this and design their security and token scoping
attributes according to their own attack vectors. The spec should
highlight these issues, but cannot solve them.
EHL
> -----Original Message-----
> From: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] On Behalf
> Of Ian McKellar
> Sent: Friday, July 02, 2010 2:10 PM
> To: Marius Scurtescu
> Cc: OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)
> Subject: Re: [OAUTH-WG] Security of user agent clients (WAS: End
user auth
> response code-and-token's scope parameter)
>
> No, that's a really simple recipe for disaster.
>
> Flickr kept opening up this security hole. They would allow
applications to get
> new tokens simply using their api key & secret and a user's session
cookies. If
> we assume that for a desktop user-agent will expose its secrets then
this is a
> really easy way to gain access to peoples' accounts.
>
> See: http://ianloic.com/2006/12/23/flickr_authentication_security/
> and: http://ianloic.com/2009/01/05/no-more-secrets/
>
> Ian
>
> On Sat, Jul 3, 2010 at 7:17 AM, Marius Scurtescu
<mscurte...@google.com <mailto:mscurte...@google.com>>
> wrote:
> > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott
<andrewarn...@gmail.com <mailto:andrewarn...@gmail.com>>
> wrote:
> >> I guess as a minimum then, user-agent clients should never be issued
> >> access tokens without explicit user interaction? Otherwise every web
> >> site around will automatically know who I am on facebook and who my
> >> friends are as soon as I authorize the one client that is popular.
> >> Or am I missing something?
> >
> > Most likely user interaction will be required for the first time, but
> > after that an immediate mode (no user interaction) is almost a must.
> > JavaScript clients will probably not be issued refresh tokens and
> > access tokens are short lived. It would not be practical to ask the
> > user every hour or so. In immediate mode there is no explicit user
> > interaction, but the user must be at the browser and have an active
> > session with the authz server.
> >
> > How would other web sites know about your facebook account? Are you
> > worried if the same JavaScript widget is embedded in multiple site and
> > that these instances share state? Or that the widget shares state with
> > the embedding site/page? Not sure about that.
> >
> > Marius
> >
> >
> >> --
> >> Andrew Arnott
> >> "I [may] not agree with what you have to say, but I'll defend to the
> >> death your right to say it." - S. G. Tallentyre
> >>
> >>
> >> On Fri, Jul 2, 2010 at 10:02 AM, Eran Hammer-Lahav
> >> <e...@hueniverse.com <mailto:e...@hueniverse.com>>
> >> wrote:
> >>>
> >>> At the end of the day, there isn't much you can do about user-agent
> >>> clients. Even a registered redirection URI doesn't really help
> >>> because that endpoint too cannot authenticate the client.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: Andrew Arnott [mailto:andrewarn...@gmail.com
<mailto:andrewarn...@gmail.com>]
> >>> Sent: Friday, July 02, 2010 9:51 AM
> >>> To: Eran Hammer-Lahav
> >>> Cc: OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)
> >>> Subject: Re: [OAUTH-WG] End user auth response code-and-token's
> >>> scope parameter
> >>>
> >>>
> >>>
> >>> Ah! Yes I'd missed the second scope parameter that web servers have
> >>> the opportunity to see. And your point makes sense.
> >>>
> >>>
> >>>
> >>> Is this reduced scope on the access token, and the encouragement for
> >>> a registered redirect_uri, the only mitigations we have for this
> >>> possible attack?
> >>>
> >>>
> >>>
> >>> Popular client app A is broadly authorized by users on the web.
> >>> Evil client app B is added as javascript on a web site. Victim
> >>> visits that web site, and the evil client quietly requests an access
> >>> token from auth server using a request claiming to be from client
> >>> app A. Since client app A wasn't required to register a
> >>> redirect_uri and did not do so, client app B is successful in
> >>> supplying its own redirect_uri and gains an access token without
> >>> user intervention or knowledge, since the user had already
> >>> authorized client A and the auth server just freely granted a new
> >>> access token. Client app B then uses AJAX to send access token
to the
> attacker, who can now exploit the access token from a separate machine.
> >>>
> >>>
> >>>
> >>> I brought this attack up once before. I really feel the spec should
> >>> forbid issuing access tokens directly to user-agent clients when
> >>> they haven't registered a redirect_uri. Another mitigation is that
> >>> implicit re-issuing of an access token to a previously authorized
> >>> client should be banned without a registered redirect_uri (although
> >>> this only reduces the risk, as the user is still presented with
the wrong
> client name).
> >>>
> >>>
> >>>
> >>> Thoughts?
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I'll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>> On Fri, Jul 2, 2010 at 9:31 AM, Eran Hammer-Lahav
> >>> <e...@hueniverse.com <mailto:e...@hueniverse.com>>
> >>> wrote:
> >>>
> >>> Scope is specific to the access token, not the code. In fact, I
> >>> expect some providers to issue an access token with a lesser scope
> >>> than that provided when exchanging the authorization code later
> >>> (which will include another scope). This is because the
> >>> authorization server can authenticate the client when using the
> authorization code and provide greater access.
> >>>
> >>>
> >>>
> >>> EHL
> >>>
> >>>
> >>>
> >>> From: oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] On
> >>> Behalf Of Andrew Arnott
> >>> Sent: Friday, July 02, 2010 9:26 AM
> >>> To: OAuth WG (oauth@ietf.org <mailto:oauth@ietf.org>)
> >>> Subject: [OAUTH-WG] End user auth response code-and-token's scope
> >>> parameter
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> If the response type is code-and-token, the authorization server
> >>> adds the codeand state parameters to the redirection URI query
> >>> component and theaccess_token, scope, and expires_in to the
> >>> redirection URI fragment using theapplication/x-www-form-
> urlencoded format as defined by...
> >>>
> >>>
> >>>
> >>> Since the scope applies equally to both the code and access_token
> >>> parameters, it seems that scope should be included in the URI query
> >>> part so it is available to the web server as well as the user-agent.
> >>> While the scope remains in the fragment, the client's web server
> >>> won't know whether the full scope it requested was actually granted.
> >>>
> >>>
> >>>
> >>> Was there an advantage to including the scope only in the #fragment,
> >>> or was this just an oversight?
> >>>
> >>>
> >>>
> >>> Thanks.
> >>>
> >>> --
> >>> Andrew Arnott
> >>> "I [may] not agree with what you have to say, but I'll defend to the
> >>> death your right to say it." - S. G. Tallentyre
> >>>
> >>>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org <mailto:OAuth@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
>
>
> --
> Ian McKellar <http://ian.mckellar.org/>
> i...@mckellar.org <mailto:i...@mckellar.org>: email | jabber | msn
> ianloic: flickr | aim | yahoo | skype | linkedin | etc.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
