There is nothing wrong with telling people that they should prevent CSRF attacks :-)
But there is no explicit state parameter in OAuth 1.0a. Do you think that implementors of 1.0a, just by reading section 11.14, are aware of the danger of Login CSRF and can figure out how to prevent it, using a pre-session cookie and implementing a state parameter that is not even mentioned in the specification? Francisco --- On Sat, 2/26/11, Brian Eaton <bea...@google.com> wrote: From: Brian Eaton <bea...@google.com> Subject: Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF To: fcore...@pomcor.com Cc: "OAuth Mailing List" <oauth@ietf.org>, "web...@ietf.org" <web...@ietf.org>, "James HManger" <james.h.man...@team.telstra.com>, "Karen P. Lewison" <kplewi...@pomcor.com> Date: Saturday, February 26, 2011, 12:36 AM I don't think the advice from the OAuth 1.0a spec is wrong: http://oauth.net/core/1.0a/#anchor38 "Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP requests are transmitted from a user that the website trusts or has authenticated. CSRF attacks on OAuth approvals can allow an attacker to obtain authorization to OAuth Protected Resources without the consent of the User. Service Providers SHOULD strongly consider best practices in CSRF prevention at all OAuth endpoints. CSRF attacks on OAuth callback URLs hosted by Consumers are also possible. Consumers should prevent CSRF attacks on OAuth callback URLs by verifying that the User at the Consumer site intended to complete the OAuth negotiation with the Service Provider." This is the purpose of the "state" parameter during the approval flows. Cheers, Brian On Fri, Feb 25, 2011 at 3:42 PM, Francisco Corella <fcore...@pomcor.com> wrote: > > Hi James, > > You raise an interesting point. I hadn't thought about the > threat of Login CSRF. > > > Q. Should an OAuth client app list the authorization server > > in the Origin header of requests to resource servers? > > > > In OAuth (delegation) flows a server dynamically issues > > credentials (such as a bearer token) to a client app to use > > in subsequent HTTP requests to other servers. To combat > > login cross-site request forgery (CSRF) attacks [1] (where > > an attacker’s server issues the attacker’s credentials to a > > client app ... > > But how will the client app get the "credentials" (bearer token) > from the wrong authorization server? > > Even though the particular attack you describe may not work, > OAuth is wide open to Login CSRF in a different way. An > attacker can legitimately obtain an authorization code, and > then cause the victim's browser to submit it to the client > application, thus logging the victim in to the client > application as the attacker (in a social login scenario such > as "log in with Facebook"). I bet all applications that use > OAuth to delegate authentication (to Facebook, Twitter, > Google, LinkedIn, Yahoo, etc.) are vulnerable to this now. > > One solution I would propose is to have the client set a > pre-session cookie in the user's browser before the first > redirection and include the value of the cookie in the local > state parameter that it sends to the authorization server. > The authorization server later returns the local state > together with the authorization code, and the browser adds > the cookie, so the client can prevent the attack by checking > that the value of the cookie agrees with the value it > included in the local state. > > Francisco > > > _______________________________________________ > 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
