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