Re: [OAUTH-WG] Auth Code Swap Attack

Anthony Nadalin <> Mon, 22 August 2011 21:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 244FC21F8CA6 for <>; Mon, 22 Aug 2011 14:58:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.466
X-Spam-Status: No, score=-7.466 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, UNRESOLVED_TEMPLATE=3.132]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GyUNu-1tKLF7 for <>; Mon, 22 Aug 2011 14:58:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AC68021F8CA3 for <>; Mon, 22 Aug 2011 14:58:40 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 22 Aug 2011 14:59:46 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Aug 2011 14:59:46 -0700
Received: from ( by ( with Microsoft SMTP Server id; Mon, 22 Aug 2011 21:59:44 +0000
Received: from mail118-db3 (localhost.localdomain []) by (Postfix) with ESMTP id 6828E1B380CC for <>; Mon, 22 Aug 2011 21:59:44 +0000 (UTC)
X-SpamScore: -31
X-BigFish: PS-31(zz9371K936eKc85fh542M98dKzz1202h1082kzz1033IL8275bh8275dhz31h2a8h668h839h61h)
X-Spam-TCS-SCL: 0:0
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:SKI;; R:internal; EFV:INT
Received-SPF: softfail (mail118-db3: transitioning domain of does not designate as permitted sender) client-ip=;; ; ;
Received: from mail118-db3 (localhost.localdomain []) by mail118-db3 (MessageSwitch) id 1314050383938519_11560; Mon, 22 Aug 2011 21:59:43 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id DEECD16B804B; Mon, 22 Aug 2011 21:59:43 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 22 Aug 2011 21:59:42 +0000
Received: from ([]) by ([]) with mapi id 14.01.0225.064; Mon, 22 Aug 2011 21:58:54 +0000
From: Anthony Nadalin <>
To: Eran Hammer-Lahav <>, Phil Hunt <>
Thread-Topic: [OAUTH-WG] Auth Code Swap Attack
Date: Mon, 22 Aug 2011 21:58:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B26C1EF377CB694EAB6BDDC8E624B6E7263E35D5SN2PRD0302MB137_"
MIME-Version: 1.0
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: Mon, 22 Aug 2011 21:58:42 -0000

Concern here is we have a protocol that is open to attacks, we need to document a way that developers can safely implement, leaving it up to the developer may not be the best way unless they know what they are doing, so more in favor of recommending the use of  state and if the developer can do something better the so be it

From: [] On Behalf Of Eran Hammer-Lahav
Sent: Monday, August 22, 2011 12:16 PM
To: Phil Hunt
Cc: OAuth WG (
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Sounds like a good compromise. I will play with the text Bill proposed and follow up with new text on the list.


From: Phil Hunt <<>>
Date: Mon, 22 Aug 2011 08:57:54 -0700
To: Eran Hammer-lahav <<>>
Cc: "<>" <<>>, "OAuth WG (<>)" <<>>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack

Eran, to summarize,

1. The server cannot tell if the client did its job - so the server can't "require" the client to implement state
2. There are many ways to enforce CSRF

There is an important "network" effect  here (and in general with OAuth) - that client decisions affect the security of the resource server and vice-versa. One could argue, that many implementers will want a solution for #1 above -- some form of mutual state validation.  This may not be of interest to today's implementers, but I know this is critical for government and financial services where fraud (and phishing) become a much larger issue.

I am beginning to believe we can't fix this now. This will likely have to be an optional RFC for higher strength anti-CSRF which specifies a standard methodology that can be verified by the server (so it can enforce that it was done).  My belief is that a standard methodology would make things easier for developers since they would have clear instructions on how to do it. Hopefully this would address folks like Facebook who are concerned developers have a hard time getting this right.

Because of this, I re-checked RFC2119 regarding making state "RECOMMENDED".  Whereas "REQUIRED" is equivalent to "MUST", "RECOMMENDED" is equivalent to SHOULD and could be used as a parameter qualifier. Though I agree, traditionally this isn't done.  However, my feeling is that the developer needs to be alerted to the importance of "state". Deciding not to use it means they should have some other technique to counter CSRF.  This is what SHOULD is meant for.  Changing to RECOMMENDED makes the calls consistent with the security consideration requirement that anti-CSRF is a MUST.



On 2011-08-21, at 10:53 PM, Eran Hammer-Lahav wrote:

-----Original Message-----
From: Phil Hunt []
Sent: Sunday, August 21, 2011 10:39 PM
To: David Recordon
Cc: Eran Hammer-Lahav; OAuth WG (<>)
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
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.
It's still just a CSRF attack.
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?
That's irrelevant. The authorization server has absolutely no way of verifying if the client is implementing a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed text requirement with "state=ni".
Would it be acceptable to change status from OPTIONAL to RECOMMENDED?
Parameters are either required or optional. We can makes it optional and recommended for a particular purpose which is consistent with the existing text.
It should be mandatory to implement CSRF protection. We agree on that and should add it to the text. We also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security consideration section and can enhance that when defining the 'state' parameter.