Re: [OAUTH-WG] Auth Code Swap Attack

Torsten Lodderstedt <> Wed, 24 August 2011 06:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEC5B21F8B57 for <>; Tue, 23 Aug 2011 23:05:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.141
X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Mrjd+p072Qbl for <>; Tue, 23 Aug 2011 23:05:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A25B21F8B3F for <>; Tue, 23 Aug 2011 23:05:07 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <>) id 1Qw6bO-0004oR-7C; Wed, 24 Aug 2011 08:06:14 +0200
Message-ID: <>
Date: Wed, 24 Aug 2011 08:06:12 +0200
From: Torsten Lodderstedt <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Eran Hammer-Lahav <>
References: <> <> <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET>
Content-Type: multipart/alternative; boundary="------------020902040208010509000109"
Cc: "OAuth WG (" <>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Aug 2011 06:05:12 -0000

making CSRF prevention a MUST and recommending the state parameter as 
implementation pattern is ok with me.


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?
> *From:*Torsten Lodderstedt []
> *Sent:* Sunday, August 21, 2011 11:04 AM
> *To:* Eran Hammer-Lahav
> *Cc:* OAuth WG (
> *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.
> *From:* <> 
> [] *On Behalf Of *Eran Hammer-Lahav
> *Sent:* Monday, August 15, 2011 9:35 AM
> *To:* OAuth WG ( <>)
> *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.
> *From:*Eran Hammer-Lahav
> *Sent:* Friday, August 12, 2011 2:53 PM
> *To:* Anthony Nadalin; OAuth WG ( <>)
> *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 < 
> <>>
> *Date: *Fri, 12 Aug 2011 12:06:36 -0700
> *To: *"OAuth WG ( <>)" 
> < <>>
> *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.
> _______________________________________________
> OAuth mailing list
>  <>