Eran, Just took a look at the text. This new version looks much improved. I think this is a good compromise.
Thanks, Phil @independentid www.independentid.com phil.h...@oracle.com On 2011-09-04, at 4:25 PM, Eran Hammer-Lahav wrote: > The corresponding 'state' parameter definition: > > RECOMMENDED. 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 parameter SHOULD be used > for preventing > cross-site request forgery as described in section 10.12. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Sunday, September 04, 2011 4:20 PM >> To: William J. Mills; Anthony Nadalin; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >> >> This is my proposed text for -21 (based on Bill's text as a starting point): >> >> 10.12. Cross-Site Request Forgery >> >> Cross-site request forgery (CSRF) is an exploit in which an attacker >> causes the user-agent of a victim end-user to follow a malicious URI >> (e.g. provided to the user-agent as a misleading link, image, or >> redirection) to a trusting server (usually established via the >> presence of a valid session cookie). >> >> A CSRF attack against the client's redirection URI allows an attacker >> to inject their own authorization code or access token, which can >> result in the client using an access token associated with the >> attacker's protected resources rather than the victim's (e.g. save >> the victim's bank account information to a protected resource >> controlled by the attacker). >> >> The client MUST implement CSRF protection for its redirection URI. >> This is typically accomplished by requiring any request sent to the >> redirection URI endpoint to include a value that binds the request to >> the user-agent's authenticated state (e.g. a hash of the session >> cookie used to authentication the user-agent). The client SHOULD >> utilize the "state" request parameter to deliver this value to the >> authorization server when making an authorization request. >> >> Once authorization has been obtained from the end-user, the >> authorization server redirects the end-user's user-agent back to the >> client with the required binding value contained in the "state" >> parameter. The binding value enables the client to validate the >> validity of the request by matching the binding value to the user- >> agent's authenticated state. The binding value used for CSRF >> protection MUST contain a non-guessable value, and the user-agent's >> authenticated state (e.g. session cookie, HTML5 local storage) MUST >> be kept in a location accessible only to the client and the user- >> agent (i.e., protected by same-origin policy). >> >> A CSRF attack against the against the authorization server's >> authorization endpoint can result in an attacker obtaining end-user >> authorization for a malicious client without involving or alerting >> the end-user. >> >> The authorization server MUST implement CSRF protection for its >> authorization endpoint, and ensure that a malicious client cannot >> obtain authorization without the awareness and explicit consent of >> the resource owner. >> >> EHL >> >> >> From: William J. Mills [mailto:wmi...@yahoo-inc.com] >> Sent: Thursday, August 25, 2011 12:11 PM >> To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >> >> I had proposed text, and I'll reprise it here with a modification to make the >> authorizaton server related explicit. >> >> 10.12. Cross-Site Request Forgery >> >> Cross-site request forgery (CSRF) is an attack whereby malicious URLs are >> sent to the user-agent of an end user (generally as hidden links or images) >> and transmitted from the user-agent the server trusts or has authenticated. >> The most commonly exploited mechanism for this is credentials held in >> cookies automatically presented by a web browser. CSRF attacks against the >> client's redirection URI allow an attacker to inject their own authorization >> code or access token, which can result in the client using an access token >> associated with the attacker's account rather than the victim's. CSRF >> attacks >> are also possible against an authorization endpoint resulting in delivering a >> user credential to an attacker. >> >> Client applications MUST implement CSRF protection for the redirection >> URI. CSRF protection for a request is data included in the request that ties >> that request to the user's authenticated state, i.e. a cryptographic >> signature >> of the user credential and the redirection URI path. Upon receipt of a >> request the client application computes the CSRF data based on the >> presented credential and compares that to the CSRF protection data >> presented in the request. CSRF protection data MUST contain a non- >> guessable value, and the client MUST keep it in a location accessible only by >> the client or the user-agent (i.e., protected by same-origin policy). The >> "state" redirection URI parameter is provided as one method of carrying >> CSRF protection data, and is RECOMMENDED to provide the greatest >> compatibility with systems implementing strong redirection URI validation. >> >> Authorization servers MUST implement CSRF protection for authorization >> requests, use of the "state" parameter is RECOMMENDED as the way to >> transmit the CSRF protection data. The CSRF protection data MUST contain a >> non-guessable value, and MUST be presented as part of the authorization >> request data (e.g. not as a cookie). Authorization servers MAY use proof of >> previous authorization by a user for a client in lieu of explicit CSRF >> protection. >> >> 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 which MUST >> then validate the received value against the stored value, or by recomputing >> the expected value of the CSRF protection data and comparing that to the >> value presented. >> >> >> >> ________________________________________ >> From: Anthony Nadalin <tony...@microsoft.com> >> To: Eran Hammer-Lahav <e...@hueniverse.com>; Torsten Lodderstedt >> <tors...@lodderstedt.net> >> Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> >> Sent: Thursday, August 25, 2011 8:11 AM >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack I have not seen any >> updated text, so I don’t believe we have consensus. Also we have a flawed >> protocol and we are not providing a fix, suggest that MUST be on the state >> also unless someone has a better fix >> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> Of Eran Hammer-Lahav >> Sent: Wednesday, August 24, 2011 7:54 AM >> To: Torsten Lodderstedt >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >> >> I believe we have full consensus on this approach. >> >> EHL >> >> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] >> Sent: Tuesday, August 23, 2011 11:06 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >> >> making CSRF prevention a MUST and recommending the state parameter as >> implementation pattern is ok with me. >> >> regards, >> Torsten. >> >> Am 21.08.2011 21:02, schrieb Eran Hammer-Lahav: >> 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 > _______________________________________________ > 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
