Re: [OAUTH-WG] Auth Code Swap Attack

[Anthony Nadalin <[e-mail]>]

Acceptable, but not ideal

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[e-mail]] 
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