Re: [OAUTH-WG] Auth Code Swap Attack

[Phil Hunt <[e-mail]>]

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
[e-mail]





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