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] On Behalf > Of Ian McKellar > Sent: Friday, July 02, 2010 2:10 PM > To: Marius Scurtescu > Cc: 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) > > 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> > wrote: > > On Fri, Jul 2, 2010 at 11:02 AM, Andrew Arnott <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> > >> 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] > >>> Sent: Friday, July 02, 2010 9:51 AM > >>> To: Eran Hammer-Lahav > >>> Cc: OAuth WG (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> > >>> 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] On > >>> Behalf Of Andrew Arnott > >>> Sent: Friday, July 02, 2010 9:26 AM > >>> To: OAuth WG (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 > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > -- > Ian McKellar <http://ian.mckellar.org/> > i...@mckellar.org: email | jabber | msn > ianloic: flickr | aim | yahoo | skype | linkedin | etc. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
