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

André DeMarre <andredemarre@gmail.com> Wed, 22 February 2012 00:38 UTC

Return-Path: <andredemarre@gmail.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 5F56721F86F2 for <oauth@ietfa.amsl.com>; Tue, 21 Feb 2012 16:38:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.883
X-Spam-Level:
X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0N88zBUVE2IQ for <oauth@ietfa.amsl.com>; Tue, 21 Feb 2012 16:38:46 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94DD221F8645 for <oauth@ietf.org>; Tue, 21 Feb 2012 16:38:46 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so8291380pbc.31 for <oauth@ietf.org>; Tue, 21 Feb 2012 16:38:46 -0800 (PST)
Received-SPF: pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) client-ip=10.68.233.74;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of andredemarre@gmail.com designates 10.68.233.74 as permitted sender) smtp.mail=andredemarre@gmail.com; dkim=pass header.i=andredemarre@gmail.com
Received: from mr.google.com ([10.68.233.74]) by 10.68.233.74 with SMTP id tu10mr81133016pbc.98.1329871126481 (num_hops = 1); Tue, 21 Feb 2012 16:38:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DFKv/vqHfg+fQgNB771WT76Nmiu76Yb5BKAC3cpT7dA=; b=H9SwRbwkMYIEPKf20LSlVkfyJXIYglM60Ir01+do4ueJt4OhOF7h9FdgGDN3pfpkAa VBOK+lC0rMv6O3UCI2Tky6yREO8VU4vof9pkG6caeTSySYw0+B+RVaJFenM2cLkSmf8Y on9oNOse4QPSgjEgU6Vsf2Y0/EMT9RMd8rqm4=
MIME-Version: 1.0
Received: by 10.68.233.74 with SMTP id tu10mr66710703pbc.98.1329871126415; Tue, 21 Feb 2012 16:38:46 -0800 (PST)
Received: by 10.68.25.193 with HTTP; Tue, 21 Feb 2012 16:38:46 -0800 (PST)
In-Reply-To: <6F478836-0DB8-4D7F-8954-5D127C0DA6AE@ve7jtb.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>
Date: Tue, 21 Feb 2012 16:38:46 -0800
Message-ID: <CAEwGkqBZfE_n7wRWN33_jT2C8Yh0LfSy5Ex2pt+34KquiCw80A@mail.gmail.com>
From: André DeMarre <andredemarre@gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "Lee, David" <david.lee10@hp.com>, Wenjie Lin <lin.820@osu.edu>, "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: Wed, 22 Feb 2012 00:38:47 -0000

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> 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
> https://www.ietf.org/mailman/listinfo/oauth
>