Re: [OAUTH-WG] Auth Code Swap Attack

[Torsten Lodderstedt <[e-mail]>]

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:[e-mail]]
> *Sent:* Sunday, August 21, 2011 11:04 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG ([e-mail])
> *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:*[e-mail] <mailto:[e-mail]> 
> [mailto:[e-mail]] *On Behalf Of *Eran Hammer-Lahav
> *Sent:* Monday, August 15, 2011 9:35 AM
> *To:* OAuth WG ([e-mail] <mailto:[e-mail]>)
> *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 ([e-mail] <mailto:[e-mail]>)
> *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 <[e-mail] 
> <mailto:[e-mail]>>
> *Date: *Fri, 12 Aug 2011 12:06:36 -0700
> *To: *"OAuth WG ([e-mail] <mailto:[e-mail]>)" 
> <[e-mail] <mailto:[e-mail]>>
> *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
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth