So far Facebook has used `state` in examples within our documentation and strongly recommend it but have not gone so far as to mandate it.
Quoting https://developers.facebook.com/docs/authentication/: > Cross site request forgery is an attack in which an trusted (authenticated > and authorized) user unknowingly performs an action on website. To prevent > this attack, you should pass an identifier in the state parameter, and then > validate the state parameter matches on the response. We strongly recommend > that any app implementing Facebook user login implement CSRF protection using > this mechanism. I'd rather clearly document this in the spec, strongly recommend a solution but not mandate this specific parameter. --David On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > I light to the recent discussion, do you still feel that changing ‘state’ > from optional to required is the best approach? > > > > EHL > > > > From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] > Sent: Sunday, August 21, 2011 11:04 AM > To: Eran Hammer-Lahav > Cc: OAuth WG (oauth@ietf.org) > > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > My intention is to require clients to implement CSRF prevention. I thought > making the state parameter mandatory would be the straightforward way. > > regards, > Torsten. > > Am 18.08.2011 08:04, schrieb Eran Hammer-Lahav: > > I would like to hear from the other 3 authors of the proposed change about > their reasons for changing the use of ‘state’ from recommended to required > for CSRF prevention. It would also help moving this issue forward if the 4 > authors can provide answers or clarifications on the issues raised below. > > > > Assuming we can count all 4 authors are in favor of making the change, I > believe we have a tie (4:4) and therefore no consensus for making it (as of > this point). However, we did identify issues with the section’s language and > clarity which we should address either way. > > > > To clarify – I am not proposing we close this issue just yet. > > > > EHL > > > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Eran Hammer-Lahav > Sent: Monday, August 15, 2011 9:35 AM > To: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > To demonstrate why making state required as proposed isn’t very helpful, > here is an incomplete list of other requirements needed to make an effective > CSRF: > > > > * State value must not be empty (a common bug in many implementations using > simple value comparison). > > > > * ‘Non-guessable’ isn’t sufficient as most developers will simply use a hash > of the session cookie, with or without salt which isn’t sufficient. We use > “cannot be generated, modified, or guessed to produce valid values” > elsewhere in the document, but this is much easier to get right for access > tokens and refresh tokens than CSRF tokens which are often just some > algorithm on top of the session cookie. > > > > * State CSRF value should be short-lived or based on a short-lived session > cookie to prevent the use of a leaked state value in multiple attacks on the > same user session once the leak is no longer viable. > > > > In addition, this is not what “state” was originally intended for. If the > working group decides to mandate a CSRF parameter, it should probably be a > new parameter with a more appropriate name (e.g. ‘csrf’). By forcing clients > to use “state” for this purpose, developers will need to use dynamic queries > for other state information which further reduces the security of the > protocol (as the draft recommends not using dynamic callback query > components). Encoding both CSRF tokens and other state information can be > non-intuitive or complicated for some developers/platforms. > > > > EHL > > > > > > > > > > From: Eran Hammer-Lahav > Sent: Friday, August 12, 2011 2:53 PM > To: Anthony Nadalin; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > This is really just a flavor of CSRF attacks. I have no objections to better > documenting it (though I feel the current text is already sufficient), but > we can't realistically expect to identify and close every possible > browser-based attack. A new one is invented every other week. > > > > The problem with this text is that developers who do no understand CSRF > attacks are not likely to implement it correctly with this information. > Those who understand it do not need the extra verbiage which is more > confusing than helpful. > > > > As for the new requirements, they are insufficient to actually accomplish > what the authors propose without additional requirements on state local > storage and verification to complete the flow. Also, the proposed text needs > clarifications as noted below. > > > > > > From: Anthony Nadalin <tony...@microsoft.com> > Date: Fri, 12 Aug 2011 12:06:36 -0700 > To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> > Subject: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > Recommended Changes to draft-ietf-oauth-v2 > > > > In section 4, request options (e.g. 4.1.1) featuring "state" should change > from: > > > > state > > OPTIONAL. An opaque value used by the client to maintain state between the > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. > > > > to: > > > > state > > REQUIRED. An opaque value used by the client to maintain state between the > request and callback. The authorization server includes this value when > redirecting the user-agent back to the client. The encoded value SHOULD > enable the client application to determine the user-context that was active > at the time of the request (see section 10.12). The value MUST NOT be > guessable or predictable, and MUST be kept confidential. > > > > > > Making the parameter required without making its usage required (I.e. "value > SHOULD enable") accomplishes nothing. Also, what does "MUST be kept > confidential" mean? Confidential from what? Why specify an "encoded value"? > > > > > > Section 10.12 Cross-Site Request Forgery > > > > Change to: > > > > Cross-site request forgery (CSRF) is a web-based attack whereby HTTP > requests are transmitted from the user-agent of an end-user the server > trusts or has authenticated. CSRF attacks enable the attacker to intermix > the attacker's security context with that of the resource owner resulting in > a compromise of either the resource server or of the client application > itself. In the OAuth context, such attacks allow an attacker to inject their > own authorization code or access token into a client, which can result in > the client using an access token associated with the attacker's account > rather than the victim's. Depending on the nature of the client and the > protected resources, this can have undesirable and damaging effects. > > In order to prevent such attacks, the client application MUST encode a > non-guessable, confidential end-user artifact and submit as the "state" > parameter to authorization and access token requests to the authorization > server. The client MUST keep the state value in a location accessible only > by the client or the user-agent (i.e., protected by same-origin policy), for > example, using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > The authorization server includes the value of the "state" parameter when > redirecting the user-agent back to the client. Upon receiving a redirect, > the client application MUST confirm that returned value of "state" > corresponds to the state value of the user-agent's user session. If the > end-user session represents an authenticated user-identity, the client MUST > ensure that the user-identity has NOT changed. > > > > > > The above text uses 'user-context' and this 'user-identity'. Neither term is > defined. > > > > EHL > > > _______________________________________________ > > 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
