Re: [OAUTH-WG] Auth Code Swap Attack

[Phil Hunt <[e-mail]>]

I think the complication here is that CSRF issues are multi-site issues where the attacker cross connecting his client with a victims resource, or a victims client with the attackers resource.

So while an individual site (e.g. Facebook) may presume little or no risk - there is a network effect here. A CSRF attacker could be using facebook to attack another site. See Yaron's original text about Plaxo/Live at the start of this thread.

Would it be reasonable to assess whether a resource site could make it mandatory based on a pre-registered client?  IOW, would Facebook want to make state mandatory for Confidential clients, but not public clients?

Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Phil

@independentid
www.independentid.com
[e-mail]





On 2011-08-21, at 6:10 PM, David Recordon wrote:

> So far Facebook has used `state` in examples within our documentation
> and strongly recommend it but have not gone so far as to mandate it.
> 
> Quoting https://developers.facebook.com/docs/authentication/:
>> Cross site request forgery is an attack in which an trusted (authenticated
>> and authorized) user unknowingly performs an action on website. To prevent
>> this attack, you should pass an identifier in the state parameter, and then
>> validate the state parameter matches on the response. We strongly recommend
>> that any app implementing Facebook user login implement CSRF protection using
>> this mechanism.
> 
> I'd rather clearly document this in the spec, strongly recommend a
> solution but not mandate this specific parameter.
> 
> --David
> 
> 
> On Sun, Aug 21, 2011 at 12:02 PM, Eran Hammer-Lahav <[e-mail]> wrote:
>> 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