Re: [OAUTH-WG] Auth Code Swap Attack

[Torsten Lodderstedt <[e-mail]>]

Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav:
> 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.

We are constantly facing the fact that a comprehensive description of 
security threats needs more space than we have in the core draft. That's 
the reason why the security document has 63 pages and that's also the 
reason why we decided to let the core spec refer to this document for 
in-depth explanations. This holds true for this threat as well.

regards,
Torsten.

>
> 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]
> https://www.ietf.org/mailman/listinfo/oauth