Re: [OAUTH-WG] open redirect in rfc6749

Antonio Sanso <asanso@adobe.com> Wed, 03 September 2014 19:59 UTC

Return-Path: <asanso@adobe.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030C21A6F01 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 12:59:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.147
X-Spam-Level:
X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJETJDlPTWBq for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 12:59:00 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3640A1A6EE9 for <oauth@ietf.org>; Wed, 3 Sep 2014 12:59:00 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB205.namprd02.prod.outlook.com (10.242.165.139) with Microsoft SMTP Server (TLS) id 15.0.1015.17; Wed, 3 Sep 2014 19:58:58 +0000
Received: from CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.122]) by CO1PR02MB206.namprd02.prod.outlook.com ([169.254.8.8]) with mapi id 15.00.1015.018; Wed, 3 Sep 2014 19:58:58 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [OAUTH-WG] open redirect in rfc6749
Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAKq4CAAA4HgIAAC3mAgAADpYCAAAMiAIAAAE8AgAACwIA=
Date: Wed, 03 Sep 2014 19:58:58 +0000
Message-ID: <6D7EE84E-26A1-4567-A68C-704269161DC5@adobe.com>
References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com> <54073D6F.6070203@redhat.com> <7A3A12C9-2A3B-48B1-BD5D-FD467EA03EE8@ve7jtb.com> <58148F80-C2DD-45C5-8D6F-CED74A90AA75@adobe.com> <5407470B.2010904@pingidentity.com> <25055629-26A9-478D-AE7A-3C295E3166EE@adobe.com> <54074B7A.7080907@pingidentity.com> <43A8E8A6-BA9B-4501-8CA3-28943236EADB@adobe.com> <387F387A-4743-488F-BBD0-8FB8232FA8E9@ve7jtb.com> <5407611D.6090405@pingidentity.com> <26BE0939-3BFE-4C06-81E7-39BF906FCF19@oracle.com> <7320F0A5-86FA-42CB-8C6D-00EBDDF1A48C@adobe.com> <41169177-EDF1-4577-8860-B0DE2CDF5C0C@oracle.com> <D1EFD4DC-F4E1-4627-BE9E-A1AEB327E2DC@oracle.com>
In-Reply-To: <D1EFD4DC-F4E1-4627-BE9E-A1AEB327E2DC@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [178.83.47.250]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;
x-forefront-prvs: 032334F434
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199003)(24454002)(189002)(51704005)(51444003)(479174003)(377454003)(46102001)(107046002)(106116001)(15974865002)(19580395003)(83716003)(15202345003)(90102001)(74502001)(77982001)(105586002)(36756003)(79102001)(2656002)(21056001)(4396001)(93886004)(83322001)(85852003)(16601075003)(587094003)(15395725005)(19580405001)(87936001)(76482001)(101416001)(99286002)(64706001)(50986999)(82746002)(76176999)(20776003)(80022001)(81342001)(92566001)(92726001)(86362001)(81542001)(33656002)(31966008)(83072002)(106356001)(74662001)(77096002)(15975445006)(85306004)(54356999)(99396002)(95666004)(110136001)(66066001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB205; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AA20CB014C30D24CB4FDE8D686133147@namprd02.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/khjk1iIAnB99GWCeK9pEMCZIp3w
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] open redirect in rfc6749
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Sep 2014 19:59:02 -0000

thanks Phil for pointing the sections out but reading them I still think the case I brought up is still a different one :)
On Sep 3, 2014, at 9:49 PM, Phil Hunt <phil.hunt@oracle.com> wrote:

> ooops,, that 6819 not 6810
> 
> Phil
> 
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
> 
> 
> 
> On Sep 3, 2014, at 12:47 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
>> in RFC6810, see section 3.5 and 4.1.5. 
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> On Sep 3, 2014, at 12:36 PM, Antonio Sanso <asanso@adobe.com> wrote:
>> 
>>> hi Phil,
>>> can you point out the relative paragraph that covers this specific case in RFC6819?
>>> On Sep 3, 2014, at 9:23 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
>>> 
>>>> I do not believe this is a flaw specific to 6749. The flaw if any is within HTTP itself (RFC7230). Covert redirect is a well known problem. There are extensive recommendations that prevent this covered in 6749 and 6819.
>>>> 
>>>> There is no protocol fix that OAuth can make since it is a trait or feature of HTTP.
>>>> 
>>>> Instead we’ve made security recommendations which are the appropriate response to this issue. Further we published 6819 that provides further guidance.
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>> 
>>>> 
>>>> 
>>>> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>>>> 
>>>>> fine, you're talking security considerations about untrusted clients; that's a different use case than the protocol flaw reason why Google would not do rfc6749 as written
>>>>> 
>>>>> Hans.
>>>>> 
>>>>> On 9/3/14, 7:52 PM, John Bradley wrote:
>>>>>> I agree that the error case where there is no UI is the problem, as it can be used inside a Iframe.
>>>>>> 
>>>>>> However error responses are generally useful.
>>>>>> 
>>>>>> OAuth core is silent on how redirect_uri are registered and if they are verified.
>>>>>> 
>>>>>> Dynamic registration should warn about OAuth errors to redirect_uri from untrusted clients.
>>>>>> 
>>>>>> For other registration methods we should update the RFC.
>>>>>> 
>>>>>> John B.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <asanso@adobe.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>>>>>>>> 
>>>>>>>> Is your concern clients that were registered using dynamic client registration?
>>>>>>> 
>>>>>>> yes
>>>>>>> 
>>>>>>>> 
>>>>>>>> Otherwise the positive case is returning a response to a valid URL that belongs to a client that was registered explicitly by the resource owner
>>>>>>> 
>>>>>>> well AFAIK the resource owner doesn’t register clients…
>>>>>>> 
>>>>>>> 
>>>>>>>> and the negative case is returning an error to that same URL.
>>>>>>> 
>>>>>>> the difference is the consent screen… in the positive case you need to approve an app.. for the error case no approval is needed,,,
>>>>>>> 
>>>>>>>> 
>>>>>>>> I fail to see the open redirect.
>>>>>>> 
>>>>>>> why?
>>>>>>> 
>>>>>>>> 
>>>>>>>> Hans.
>>>>>>>> 
>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote:
>>>>>>>>> 
>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt <hzandbelt@pingidentity.com
>>>>>>>>> <mailto:hzandbelt@pingidentity.com>> wrote:
>>>>>>>>> 
>>>>>>>>>> Let me try and approach this from a different angle: why would you
>>>>>>>>>> call it an open redirect when an invalid scope is provided and call it
>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is provided?
>>>>>>>>> 
>>>>>>>>> as specified below in the positive case (namely when the correct scope
>>>>>>>>> is provided) the resource owner MUST approve the app via the consent
>>>>>>>>> screen (at least once).
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Hans.
>>>>>>>>>> 
>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote:
>>>>>>>>>>> hi John,
>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <ve7jtb@ve7jtb.com
>>>>>>>>>>> <mailto:ve7jtb@ve7jtb.com>
>>>>>>>>>>> <mailto:ve7jtb@ve7jtb.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker.
>>>>>>>>>>>> 
>>>>>>>>>>>> The issue is that the AS may be allowing client registrations with
>>>>>>>>>>>> arbitrary redirect_uri.
>>>>>>>>>>>> 
>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a client
>>>>>>>>>>>> controls the redirect_uri it is registering.
>>>>>>>>>>>> 
>>>>>>>>>>>> I think that if anything it may be the registration step that needs
>>>>>>>>>>>> the security consideration.
>>>>>>>>>>> 
>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It would be
>>>>>>>>>>> pretty unpractical to block this at registration time….
>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely returning
>>>>>>>>>>> 400 with the cause of the error..
>>>>>>>>>>> 
>>>>>>>>>>> *400.* That’s an error.
>>>>>>>>>>> 
>>>>>>>>>>> *Error: invalid_scope*
>>>>>>>>>>> 
>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]}
>>>>>>>>>>> 
>>>>>>>>>>> said that I hope you all agree this is an issue in the spec so far….
>>>>>>>>>>> 
>>>>>>>>>>> regards
>>>>>>>>>>> 
>>>>>>>>>>> antonio
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> John B.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke <bburke@redhat.com
>>>>>>>>>>>> <mailto:bburke@redhat.com>
>>>>>>>>>>>> <mailto:bburke@redhat.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I don't understand.  The redirect uri has to be valid in order for a
>>>>>>>>>>>>> redirect to happen.  The spec explicitly states this.
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote:
>>>>>>>>>>>>>> hi *,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are vulnerable to open
>>>>>>>>>>>>>> redirect.
>>>>>>>>>>>>>> Let me explain, reading [0]
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or mismatching
>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing or invalid,
>>>>>>>>>>>>>> the authorization server SHOULD inform the resource owner of the
>>>>>>>>>>>>>> error and MUST NOT automatically redirect the user-agent to the
>>>>>>>>>>>>>> invalid redirection URI.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> If the resource owner denies the access request or if the request
>>>>>>>>>>>>>> fails for reasons other than a missing or invalid redirection URI,
>>>>>>>>>>>>>> the authorization server informs the client by adding the following
>>>>>>>>>>>>>> parameters to the query component of the redirection URI using the
>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix B
>>>>>>>>>>>>>> <https://tools.ietf.org/html/rfc6749#appendix-B>:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Now let’s assume this.
>>>>>>>>>>>>>> I am registering a new client to thevictim.com
>>>>>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/>>
>>>>>>>>>>>>>> <http://victim.com <http://victim.com/>>
>>>>>>>>>>>>>> provider.
>>>>>>>>>>>>>> I register redirect uriattacker.com
>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.com <http://attacker.com/>>
>>>>>>>>>>>>>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am redirected
>>>>>>>>>>>>>> back to
>>>>>>>>>>>>>> attacker.com <http://attacker.com/><http://attacker.com
>>>>>>>>>>>>>> <http://attacker.com/>> <http://attacker.com <http://attacker.com/>>.
>>>>>>>>>>>>>> Namely I prepare a url that is in this form:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> and this is works as an open redirector.
>>>>>>>>>>>>>> Of course in the positive case if all the parameters are fine this
>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the app via the
>>>>>>>>>>>>>> consent screen (at least once).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> A solution would be to return error 400 rather than redirect to the
>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do)
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> WDYT?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> antonio
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>>>>> OAuth@ietf.org
>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Bill Burke
>>>>>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>>>>>> http://bill.burkecentral.com
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> 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><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
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>>> hzandbelt@pingidentity.com <mailto:hzandbelt@pingidentity.com>| Ping
>>>>>>>>>> Identity
>>>>>>>> 
>>>>>>>> --
>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>> hzandbelt@pingidentity.com | Ping Identity
>>>>>>> 
>>>>> 
>>>>> -- 
>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>> hzandbelt@pingidentity.com | Ping Identity
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>