Re: [OAUTH-WG] Auth Code Swap Attack
Phil Hunt <phil.hunt@oracle.com> Mon, 22 August 2011 05:37 UTC
Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51BE21F859E for <oauth@ietfa.amsl.com>; Sun, 21 Aug 2011 22:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.182
X-Spam-Level:
X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=-0.583, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKsVcNZ+Hxvs for <oauth@ietfa.amsl.com>; Sun, 21 Aug 2011 22:37:40 -0700 (PDT)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 99D5D21F8559 for <oauth@ietf.org>; Sun, 21 Aug 2011 22:37:40 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p7M5cfQS017238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 22 Aug 2011 05:38:43 GMT
Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p7M5cepF000015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Aug 2011 05:38:40 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p7M5cYWU023887; Mon, 22 Aug 2011 00:38:35 -0500
Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 21 Aug 2011 22:38:34 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <CAB_mRgOWL17a_JJ7hZ1xJv5032scJ7fGE=42S=gjeaf_FNds_w@mail.gmail.com>
Date: Sun, 21 Aug 2011 22:38:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com>
References: <B26C1EF377CB694EAB6BDDC8E624B6E723BA5043@SN2PRD0302MB137.namprd03.prod.outlook.com> <CA6AE9D9.17DE9%eran@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAB_mRgOWL17a_JJ7hZ1xJv5032scJ7fGE=42S=gjeaf_FNds_w@mail.gmail.com>
To: David Recordon <recordond@gmail.com>
X-Mailer: Apple Mail (2.1084)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4E51EB63.004C:SCFMA922111,ss=1,re=-6.300,fgs=0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 05:37:41 -0000
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 phil.hunt@oracle.com 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 <eran@hueniverse.com> 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:torsten@lodderstedt.net] >> Sent: Sunday, August 21, 2011 11:04 AM >> To: Eran Hammer-Lahav >> Cc: OAuth WG (oauth@ietf.org) >> >> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of >> Eran Hammer-Lahav >> Sent: Monday, August 15, 2011 9:35 AM >> To: OAuth WG (oauth@ietf.org) >> 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 (oauth@ietf.org) >> 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 <tonynad@microsoft.com> >> Date: Fri, 12 Aug 2011 12:06:36 -0700 >> To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org> >> 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 >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Auth Code Swap Attack William J. Mills
- Re: [OAUTH-WG] Auth Code Swap Attack Phillip Hunt
- [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Torsten Lodderstedt
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack William J. Mills
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack John Kemp
- Re: [OAUTH-WG] Auth Code Swap Attack John Kemp
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin
- Re: [OAUTH-WG] Auth Code Swap Attack Barry Leiba
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Barry Leiba
- Re: [OAUTH-WG] Auth Code Swap Attack John Kemp
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Barry Leiba
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Blaine Cook
- Re: [OAUTH-WG] Auth Code Swap Attack William J. Mills
- Re: [OAUTH-WG] Auth Code Swap Attack William J. Mills
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin
- Re: [OAUTH-WG] Auth Code Swap Attack Torsten Lodderstedt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack David Recordon
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Torsten Lodderstedt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Barry Leiba
- Re: [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Phil Hunt
- Re: [OAUTH-WG] Auth Code Swap Attack Eran Hammer-Lahav
- Re: [OAUTH-WG] Auth Code Swap Attack Anthony Nadalin