Hi James, It would help if you would spell out an attack flow, step by step, and point out the practical consequences of the attack.
Thanks, Francisco --- On Tue, 3/1/11, Manger, James H <james.h.man...@team.telstra.com> wrote: From: Manger, James H <james.h.man...@team.telstra.com> Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF To: "fcore...@pomcor.com" <fcore...@pomcor.com>, "OAuth Mailing List" <oauth@ietf.org> Cc: "Karen P. Lewison" <kplewi...@pomcor.com> Date: Tuesday, March 1, 2011, 6:59 AM > The attack is only possible if there are multiple independent authorization > servers that don't trust each other. And there are. Facebook, Twitter, Photos-are-us, Xyz… can operate authorization servers; they are all independent; and don’t particularly trust each other. The attack doesn’t require a single resource server to trust all these independent authorization servers. > By far the most widespread deployment of OAuth is for social login, as in > "log in with Facebook". In that case the authorization server is a Facebook > endpoint, the resource servers are Facebook endpoints, and the attack is not > possible You are probably right that this attack is not possible against a client app offering a “login with facebook” button. Such a client is hardwired to work with a single service – which is one (very limiting) way to avoid these attacks. A client accepting login from any social network (even ones the client hasn’t heard of) could be susceptible this attack. The “other” social network returns a token that it actually got from Facebook and gets the client app to use it at Facebook. -- James Manger From: Francisco Corella [mailto:fcore...@pomcor.com] Sent: Tuesday, 1 March 2011 4:17 PM To: OAuth Mailing List; Manger, James H Cc: Karen P. Lewison Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF Hi James, I think I got it now. Thanks for explaining it so patiently. The attack is only possible if there are multiple independent authorization servers that don't trust each other. But the OAuth specification talks about multiple resource servers but only one authorization server. I think there is an implicit assumption that the multiple resource servers will only accept tokens from the one authorization server. By far the most widespread deployment of OAuth is for social login, as in "log in with Facebook". In that case the authorization server is a Facebook endpoint, the resource servers are Facebook endpoints, and the attack is not possible. Francisco --- On Tue, 3/1/11, Manger, James H <james.h.man...@team.telstra.com> wrote: From: Manger, James H <james.h.man...@team.telstra.com> Subject: RE: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF To: "fcore...@pomcor.com" <fcore...@pomcor.com>, "OAuth Mailing List" <oauth@ietf.org> Cc: "Karen P. Lewison" <kplewi...@pomcor.com> Date: Tuesday, March 1, 2011, 12:43 AM Francisco, >> A client that follows HTTP redirects (or Link: header or any >> other variety of hypertext) might get directed to an 2nd >> service while still using the token from the 1st service. > But why would a legitimate authorization server redirect the > client to an attacker's server? It can happen the other way around. The 1st service acts maliciously, forwarding a token that was actually obtained from the 2nd service. The client then uses that token to make requests to the 2nd service – because it thinks it is part of the 1st service. The core issue is that a client gets a opaque token from one service and will use it to access other resources. The token is opaque to the client: 1. The client cannot check that the token was originally issued by this service (as opposed to this service forwarding a token from elsewhere); 2. The client cannot check that the token was meant for itself (as opposed to being forwarded from another client); 3. The client isn’t told by the token issuer where it should & shouldn’t be used (ie the boundary of the services); 4. The client isn’t told by a resource server which sources of tokens are legitimate. One way to avoid some of these issues is to hardwire clients to a specific service – which is very limiting. Another way is to have a standard token format – which is limiting, and a big burden on clients. A better way is to accept points 1 & 2; address 3 by listing resource sites in token responses; and address 4 obliquely by listing the authorization server in the “Origin” HTTP request header. Then it doesn’t matter if a client unwittingly connects with an attacker’s service (just as it shouldn’t matter to a legitimate web site if their web browser clients unwittingly visit malicious or compromised web sites). -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
