Perfect. Thanks Phil. EHL
On Sep 6, 2011, at 20:42, "Phil Hunt" <[email protected]> wrote: > 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 > [email protected] > > > > > > 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: [email protected] [mailto:[email protected]] 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 ([email protected]) >>> 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:[email protected]] >>> Sent: Thursday, August 25, 2011 12:11 PM >>> To: Anthony Nadalin; Eran Hammer-Lahav; Torsten Lodderstedt >>> Cc: OAuth WG ([email protected]) >>> 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 <[email protected]> >>> To: Eran Hammer-Lahav <[email protected]>; Torsten Lodderstedt >>> <[email protected]> >>> Cc: "OAuth WG ([email protected])" <[email protected]> >>> 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: [email protected] [mailto:[email protected]] On Behalf >>> Of Eran Hammer-Lahav >>> Sent: Wednesday, August 24, 2011 7:54 AM >>> To: Torsten Lodderstedt >>> Cc: OAuth WG ([email protected]) >>> Subject: Re: [OAUTH-WG] Auth Code Swap Attack >>> >>> I believe we have full consensus on this approach. >>> >>> EHL >>> >>> From: Torsten Lodderstedt [mailto:[email protected]] >>> Sent: Tuesday, August 23, 2011 11:06 PM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG ([email protected]) >>> 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:[email protected]] >>> Sent: Sunday, August 21, 2011 11:04 AM >>> To: Eran Hammer-Lahav >>> Cc: OAuth WG ([email protected]) >>> 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: [email protected] [mailto:[email protected]] On Behalf >>> Of Eran Hammer-Lahav >>> Sent: Monday, August 15, 2011 9:35 AM >>> To: OAuth WG ([email protected]) >>> 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 ([email protected]) >>> 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 <[email protected]> >>> Date: Fri, 12 Aug 2011 12:06:36 -0700 >>> To: "OAuth WG ([email protected])" <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
