Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

Dan Taflin <dan.taflin@gettyimages.com> Fri, 24 February 2012 16:57 UTC

Return-Path: <dan.taflin@gettyimages.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 3A85B21F867F for <oauth@ietfa.amsl.com>; Fri, 24 Feb 2012 08:57:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 M3qouorUyo0A for <oauth@ietfa.amsl.com>; Fri, 24 Feb 2012 08:57:47 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F221F8802 for <oauth@ietf.org>; Fri, 24 Feb 2012 08:57:46 -0800 (PST)
Received: from mail203-ch1-R.bigfish.com (10.43.68.251) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.23; Fri, 24 Feb 2012 16:57:46 +0000
Received: from mail203-ch1 (localhost [127.0.0.1]) by mail203-ch1-R.bigfish.com (Postfix) with ESMTP id 514C34203B1; Fri, 24 Feb 2012 16:57:46 +0000 (UTC)
X-SpamScore: -33
X-BigFish: VPS-33(zz9371Ic89bh936eKc85dh1432N98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h)
X-Forefront-Antispam-Report: CIP:216.169.250.56; KIP:(null); UIP:(null); IPV:NLI; H:SEAPXCH10CAHT02.amer.gettywan.com; RD:london.webmail.gettyimages.com; EFVD:NLI
Received-SPF: pass (mail203-ch1: domain of gettyimages.com designates 216.169.250.56 as permitted sender) client-ip=216.169.250.56; envelope-from=dan.taflin@gettyimages.com; helo=SEAPXCH10CAHT02.amer.gettywan.com ; gettywan.com ;
Received: from mail203-ch1 (localhost.localdomain [127.0.0.1]) by mail203-ch1 (MessageSwitch) id 1330102662458423_25703; Fri, 24 Feb 2012 16:57:42 +0000 (UTC)
Received: from CH1EHSMHS025.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242]) by mail203-ch1.bigfish.com (Postfix) with ESMTP id 6565AE004D; Fri, 24 Feb 2012 16:57:42 +0000 (UTC)
Received: from SEAPXCH10CAHT02.amer.gettywan.com (216.169.250.56) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 24 Feb 2012 16:57:39 +0000
Received: from SEAPXCH10MBX01.amer.gettywan.com ([fe80::f054:280d:92db:5fff]) by SEAPXCH10CAHT02.amer.gettywan.com ([::1]) with mapi id 14.01.0355.002; Fri, 24 Feb 2012 08:55:38 -0800
From: Dan Taflin <dan.taflin@gettyimages.com>
To: Wenjie Lin <lin.820@osu.edu>, Kristoph <kristoph@gmail.com>
Thread-Topic: [OAUTH-WG] A Scope Attack against OAuth 2.0
Thread-Index: AQHM8pAQdzX7fHWCz0yt2jdPwxIvOJZMQrTQ
Date: Fri, 24 Feb 2012 16:55:38 +0000
Message-ID: <429493818451304B84EC9A0797B5D8584506B4@SEAPXCH10MBX01.amer.gettywan.com>
References: <CAGmQQ9eorSS8jWgHZzw_Bq6Eb4Qj+fZ0NUuQx_KJwC_rasUCnA@mail.gmail.com> <OF7789D618.84BDC5CF-ON4A2579A8.0023CB58-4A2579A8.0024278F@au1.ibm.com> <5D97D44A-FF8A-4E67-B22D-FB6019162800@ve7jtb.com> <CAGmQQ9fA6DT=-uBZUFgB=Kz6zr=eGSQUUp6X0w1QyD=O0wZy5Q@mail.gmail.com> <1329626093.59538.YahooMailNeo@web31804.mail.mud.yahoo.com> <CAGmQQ9egR9DGg6LTQVzVxiq1of=WT2Ysv9EEzoK+5b7evwfiOg@mail.gmail.com> <1329860601.42679.YahooMailNeo@web31806.mail.mud.yahoo.com> <5F0D5C92-1228-4A3E-8CFF-05DC309B4084@ve7jtb.com> <2BFDC979-1767-4CD7-9D22-B7657EB15121@gmail.com> <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.com> <CAEwGkqBZfE_n7wRWN33_jT2C8Yh0LfSy5Ex2pt+34KquiCw80A@mail.gmail.com> <C9A3D0A2-C845-4C71-90EC-1B3D01F48627@ve7jtb.com> <CAGmQQ9egdL-TtHtYpRUtL+6CNK=BfRWTM1J4gDZ2akivBokqMQ@mail.gmail.com> <34134676-9D51-4975-AD77-8AD34C3342B7@gmail.com> <CAGmQQ9exFKLCC3nbabgcoDhhfQxfDUcwydORbTtqh7v=tzwW5g@mail.gmail.com>
In-Reply-To: <CAGmQQ9exFKLCC3nbabgcoDhhfQxfDUcwydORbTtqh7v=tzwW5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.192.68.44]
Content-Type: multipart/alternative; boundary="_000_429493818451304B84EC9A0797B5D8584506B4SEAPXCH10MBX01ame_"
MIME-Version: 1.0
X-OriginatorOrg: gettyimages.com
Cc: "Lee, David" <david.lee10@hp.com>, "oauth@ietf.org (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
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: Fri, 24 Feb 2012 16:57:52 -0000

Thereby depriving the client of visibility on the social network. Yes, this is a hack, by the user, against the client, and there is material harm. The user is getting something without giving the client what was originally promised.

Of course, the client will quickly discover the hack, and could take whatever action it deems appropriate, such as shutting itself down with an error message. The question is, should the oauth protocol provide the client with the information up front by providing scope information along with the access token?

Dan

From: Wenjie Lin [mailto:lin.820@osu.edu]
Sent: Thursday, February 23, 2012 5:03 PM
To: Kristoph
Cc: Lee, David; oauth@ietf.org (oauth@ietf.org)
Subject: Re: [OAUTH-WG] A Scope Attack against OAuth 2.0

As we have shown in our Feb 17th email, the negative consequence is a violation by the user of the service agreement, that is, the user is able to play the game but the client cannot post messages on behalf of the user.

"Scope Attack
OAuth authorization of services is associated with service agreement scope. For instance, Client provides an online game to User with a service agreement scope A: User authorizes Client to access his profile information and to post messages on his behalf. A malicious User can request for online game with service agreement scope A, manipulate the scope field, and change it to scope B: User authorizes Client to access his profile information. User can still play the games,  yet Client can't post messages on User's behalf, as originally agreed."

- W. Lin and D. Lee

On Thu, Feb 23, 2012 at 4:22 PM, Kristoph <kristoph@gmail.com<mailto:kristoph@gmail.com>> wrote:
Privilege de-escalation is not an attack. Your argument comes down to "I can change something and no error is shown so it's an attack" but you've not actually shown any sort of negative consequence because, you know, there isn't one.

]{

On Feb 23, 2012, at 3:55 PM, Wenjie Lin wrote:

> We assume that the authorization server is trustworthy and won't do anything that violates the spec. We want to prevent attacks by the client on the user, as well as the attacks by the user on the client.
>
> The scope attack is by the user on the client. From the point view of the user it is not an attack. However, the client takes it as an attack; the user violates the service agreement by the client who may have no knowledge about it, unless the authorization server always sends him the authorized scope information when granting an access token, as we've proposed, and the client can figure out the difference/violation and decide how to deal with it.
>
> When the client identifies the difference between his specified scope and that in the access token, he can choose to abort or continue the service, or take other actions. This is an implementation issue and is beyond the scope of OAuth. There are other possible anomalies from implementations, such as revocation of the scope by the user. However, they are not well specified in the current spec and we take them as an implementation rather than a protocol issue.
>
> There might be applications where the client would not perceive scope attack as an attack if he could allow any changes of the service agreement scope by the user. If OAuth were aimed for such clients only, it would significantly limit the applicability of the protocol.
>
> We appreciate the insightful discussions on how the client could check and handle the scope differences and beyond. They are extremely helpful for the implementers.
>
> -W. Lin and D. Lee
>
> On Tue, Feb 21, 2012 at 4:59 PM, John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrote:
> Yes,  OpenID Connect deals with the issue by using a signed request extension in the cases where the client needs to be certain the request is only from the legitimate client and not tampered with.
>
> As you observe anyone can send a request the client_id and redirect_uri are not secret in any way.
>
> Though a well behaved client should be using state to check for XSRF attacks. (that is a real attack)
>
> Signed requests have uses,  but are not core to OAuth.
>
> John B.
> On 2012-02-21, at 9:38 PM, André DeMarre wrote:
>
> > The consensus seems to be, and I agree, that this shouldn't be
> > considered an "attack," but that's really just nomenclature. I do
> > concede that there is a spec issue here that I failed to appreciate at
> > first. Where draft-ietf-oauth-v2-23 section 3.3 says "If the issued
> > access token scope is different from the one requested by the client,"
> > it suggests that the authorization server knows what was requested by
> > the client. That isn't strictly true; it only knows what was in the
> > authorization request, not who put it there. For the client to truly
> > know what the auth server wants, (1) it would need to communicate
> > directly with the client, (2) the client would need to preregister its
> > desired scope, or (3) the client would need to sign a message that the
> > user passes to the authorization endpoint. 1 and 3 are clearly not
> > compatible with the spec, 2 might be; but that's not the point.
> >
> > A more correct statement in section 3.3 would be "If the issued access
> > token scope is different from the one in the authorization request..."
> >
> > Regards,
> > Andre DeMarre
> >
> > On Tue, Feb 21, 2012 at 3:01 PM, John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wrote:
> >>
> >> On 2012-02-21, at 7:32 PM, Nicholas Devenish wrote:
> >>
> >>>
> >>> On 21 Feb 2012, at 21:59, John Bradley wrote:
> >>>> This 'attack'  is one that only works with badly designed clients that are making unwarranted assumptions about the behaviour of the Authorization server.
> >>>
> >>> Unwarranted assumptions? The spec in 3.3 says:
> >>>
> >>> "If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted."
> >>>
> >>> - It says MUST; therefore any server that doesn't do this is non-compliant?
> >>> - It says scope different from the one requested by the *client*. The possibility that the resource owner intercepts this request and changes it doesn't seem to be considered here (it is not strictly the clients request if that happens)
> >>> - The purpose seems to be that the client should be told if the scope changes; this would be important if the client requires a certain scope level to work (though this could be solved more generally in many other ways that wouldn't be in the scope of the oauth spec)
> >>>
> >>> Thus, assuming that the server is stating compliance, isn't the assumption completely warranted?
> >>
> >> No the authorization server may at any time for any reason remove a scope from a granted access_token or refresh_token.
> >>
> >> Reporting back changes in scopes granted along with the access_token is a convenience not a security feature.
> >>
> >> Assuming it is a security feature and those scopes will continue to be valid for the token after granting is a bad design given the OAuth 2 spec.
> >>>
> >>>> The only way for a client to know if a token has a scope it to try it, or use a introspection endpoint.  End of story.
> >>>
> >>> An introspection endpoint obviously isn't part of the specification, so isn't relevant to the discussion (though it solves the discussed facebook issue).
> >>>
> >>> You are right though, that the only way for a client to know for sure is to try to use it; Even if the spec mandated always returning the scope to the client, the user could always intercept the return redirection (assuming a non-confidential client) and change the scope there.
> >>>
> >>> Perhaps MUST should change to SHOULD, given that this essentially seems unenforceable?
> >>
> >> A SHOULD may lead people to the conclusion that it is secure.   I am happy with saying it is not secure the only want to know is to have the client be prepared to deal with tokens that do not contain the desired scope when used.   That is the only 100% solution.
> >>
> >> John B.
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org<mailto:OAuth@ietf.org>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
>
>
>
>
> --
> Wenjie Lin
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth



--
Wenjie Lin