Re: [OAUTH-WG] Auth Code Swap Attack
Eran Hammer-Lahav <eran@hueniverse.com> Mon, 15 August 2011 06:32 UTC
Return-Path: <eran@hueniverse.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 BFC3D11E8083 for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 pkA86fqCnLWv for <oauth@ietfa.amsl.com>; Sun, 14 Aug 2011 23:32:20 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id BC3FB21F8541 for <oauth@ietf.org>; Sun, 14 Aug 2011 23:32:20 -0700 (PDT)
Received: (qmail 30951 invoked from network); 15 Aug 2011 06:33:05 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Aug 2011 06:33:05 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 14 Aug 2011 23:33:05 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: "eran@sled.com" <eran@sled.com>, Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sun, 14 Aug 2011 23:31:53 -0700
Thread-Topic: [OAUTH-WG] Auth Code Swap Attack
Thread-Index: AcxZy7BgMPPKPL7KSQOAnbJwNCUASQBSUo4A
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234502498CDDB@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E46207A.6080404@lodderstedt.net> <CA6BD89B.17E85%eran@hueniverse.com>
In-Reply-To: <CA6BD89B.17E85%eran@hueniverse.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.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, 15 Aug 2011 06:32:21 -0000
I'm using my proposed text in -21. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Saturday, August 13, 2011 8:14 AM > To: Torsten Lodderstedt > Cc: OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > Again, the idea that you can produce a comprehensive description of security > threat is impractical if you are going to include every browser-based attack > and its remedies. OAuth use of browser redirection imports almost every > possible attack vector on the web. That's my point. > People constantly bring up these attack vectors, and in multiple flavors and > variations, as if *anyone* can produce a complete list of these issues. > > Now, this doesn't mean we should not try to be comprehensive but this can > go on forever. > > The changes to 10.12 seem reasonable with the exception of the new > MUSTs. > I disagree that we should mandate clients to use the state parameter as the > only CSRF protection vector, especially in an evolving web environment. We > can still include a MUST for verifying that the user redirected to the > authorization server is the same user coming back, and highlight the state > parameter as one way to accomplish that. > > How about: > > > state: OPTIONAL. An opaque value used by the client to maintain state > between the request and redirection. The authorization server includes this > value when redirecting the user-agent back to the client. Use of the "state" > parameter is RECOMMENDED for preventing cross-site request forgery as > described in Section 10.12. > > > > > Section 10.12 Cross-Site Request Forgery > > > 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 the client, which can result in the > client associating the attacker's protected resources to the victim's account > on the client. 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 MUST employ CSRF protection. > > It is strongly RECOMMENDED for the client to utilize the "state" request > parameter with authorization requests to the authorization server. When > used for CSRF prevention, the "state" request parameter MUST contain a > non-guessable value, which the client MUST also store with the resource > owner's user-agent in a location accessible only to the client or the resource > owner's user-agent (i.e., protected by same-origin policy). For example, the > client can using a DOM variable, HTTP cookie, or HTML5 client-side storage. > > > When redirecting the resource owner's user-agent back to the client, the > authorization server includes the value of the "state" parameter. Upon > receiving the redirection request, the client MUST confirm that returned > value of the "state" parameter matches the value stored with the resource > owner's user-agent. > > > EHL > > > > > From: Torsten Lodderstedt <torsten@lodderstedt.net> > Date: Fri, 12 Aug 2011 23:58:02 -0700 > To: Eran Hammer-lahav <eran@hueniverse.com> > Cc: Anthony Nadalin <tonynad@microsoft.com>, "OAuth WG > (oauth@ietf.org)" > <oauth@ietf.org> > Subject: Re: [OAUTH-WG] Auth Code Swap Attack > > > > > > > > > > > > > > > > > > Am 12.08.2011 23:52, schrieb Eran Hammer-Lahav: > > > > 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. > > > > > > > > We are constantly facing the fact that a comprehensive description > > of security threats needs more space than we have in the core draft. > > That's the reason why the security document has 63 pages and that's > > also the reason why we decided to let the core spec refer to this > > document for in-depth explanations. This holds true for this threat > > as well. > > > > regards, > > Torsten. > > > > > > > > > > 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.orghttps://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