I felt the argument provided was persuasive and that the current spec leaves 
implementers open to attack. I get concerned when the core spec says "OPTIONAL" 
for state and then Security Considerations says REQUIRED. The inconsistency 
seemed to be a flaw in draft 20.

As to your comment about a tie vote, all that shows is a lack of consensus. 
Clearly we need to keep working on some more proposals.

I think it is reasonable to determine whether MUST is appropriate in all cases. 
I agree with what you said earlier, we should have more specific language other 
then "of sufficient complexity" to describe the value of the state parameter. 

I saw a proposal by William Mills that I would like to see more discussion on.

Phil

@independentid
www.independentid.com
phil.h...@oracle.com





On 2011-08-17, at 11:04 PM, Eran Hammer-Lahav wrote:

> 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

Reply via email to