Re: [OAUTH-WG] open redirect in rfc6749

Antonio Sanso <asanso@adobe.com> Wed, 03 September 2014 19:52 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 862931A6F92 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 12:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.146
X-Spam-Level:
X-Spam-Status: No, score=-0.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, 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 sKokrn87LEtP for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 12:52:42 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6241A6EFC for <oauth@ietf.org>; Wed, 3 Sep 2014 12:52:42 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB208.namprd02.prod.outlook.com (10.242.165.150) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 19:52:40 +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:52:40 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Takahiko Kawasaki <daru.tk@gmail.com>
Thread-Topic: [OAUTH-WG] open redirect in rfc6749
Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQCAAAP4AIAAARkAgAAKq4CAAA4HgIAAC3mAgAACrYCAAAVpgA==
Date: Wed, 03 Sep 2014 19:52:40 +0000
Message-ID: <1ADACEBA-AF95-42B3-A2C2-687AA7CDD193@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> <CAGpwqP-=RhLjCc6hwd+hwq6+0-OU=CmnQZiwf6=a1hkQdXktiQ@mail.gmail.com>
In-Reply-To: <CAGpwqP-=RhLjCc6hwd+hwq6+0-OU=CmnQZiwf6=a1hkQdXktiQ@mail.gmail.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:(24454002)(377424004)(51444003)(51704005)(189002)(479174003)(377454003)(199003)(46102001)(101416001)(74662001)(99286002)(19617315012)(87936001)(81342001)(93886004)(110136001)(90102001)(76482001)(19580405001)(74502001)(105586002)(106116001)(106356001)(92566001)(54356999)(14971765001)(86362001)(64706001)(107046002)(20776003)(95666004)(85306004)(81542001)(16601075003)(16236675004)(2656002)(50986999)(83716003)(99396002)(82746002)(4396001)(15202345003)(92726001)(19580395003)(15975445006)(77096002)(76176999)(85852003)(15395725005)(21056001)(80022001)(83072002)(83322001)(31966008)(33656002)(79102001)(77982001)(66066001)(587094003)(36756003)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB208; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_1ADACEBAAF9542B3A2C2687AA7CDD193adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gYg-qu1sytrNdlzAxmsNF28vM8c
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:52:45 -0000

hi Takahiko

On Sep 3, 2014, at 9:33 PM, Takahiko Kawasaki <daru.tk@gmail.com<mailto:daru.tk@gmail.com>> wrote:

I think the point is that the registered redirect URI is evil, meaning that the person who registered the client application is evil. I don't think the spec can take any countermeasure against this case.

If the registered redirect URI is evil, the issue happens even in the case where the scope is valid and consent from the end-user has been obtained.

well in this case the consent screen is there …. in the case I pointed out the redirect happens automatically

That is, an attacker would prepare an HTML page at http://attacker.com<http://attacker.com/> which says "Sorry, an error occurred. Please re-authorize this application." and has a login form that mimics the login form of victim.com<http://victim.com/>.

IMHO, all we can do is to educate people like "Be cautious when you are requested to login again.”

this is another case different from a normal open redirect IMHO


Best Regards,
Takahiko Kawasaki


2014-09-04 4:23 GMT+09:00 Phil Hunt <phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>>:
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<http://www.independentid.com/>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>



On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <hzandbelt@pingidentity.com<mailto: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<mailto:asanso@adobe.com>> wrote:
>>>
>>>
>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandbelt@pingidentity.com<mailto: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>
>>>>> <mailto: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<mailto: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<mailto: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://thevictim.com/>
>>>>>>>>>> <http://victim.com/><http://victim.com<http://victim.com/> <http://victim.com/>>
>>>>>>>>>> <http://victim.com<http://victim.com/> <http://victim.com/>>
>>>>>>>>>> provider.
>>>>>>>>>> I register redirect uriattacker.com<http://uriattacker.com/>
>>>>>>>>>> <http://attacker.com/><http://attacker.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/>> <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<mailto:OAuth@ietf.org>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Bill Burke
>>>>>>>>> JBoss, a division of Red Hat
>>>>>>>>> http://bill.burkecentral.com<http://bill.burkecentral.com/>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org<mailto: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> <mailto:OAuth@ietf.org<mailto: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> <mailto: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> <mailto:hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com>>| Ping
>>>>>> Identity
>>>>
>>>> --
>>>> Hans Zandbelt              | Sr. Technical Architect
>>>> hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com> | Ping Identity
>>>
>
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com<mailto:hzandbelt@pingidentity.com> | Ping Identity
>
> _______________________________________________
> 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

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