Re: [OAUTH-WG] open redirect in rfc6749

Antonio Sanso <asanso@adobe.com> Wed, 03 September 2014 16:56 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 804011A0362 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 09:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 fNZqQyKuojRC for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 09:56:16 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97EFB1A0368 for <oauth@ietf.org>; Wed, 3 Sep 2014 09:56:15 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB207.namprd02.prod.outlook.com (10.242.165.145) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 16:56:13 +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 16:56:13 +0000
From: Antonio Sanso <asanso@adobe.com>
To: Hans Zandbelt <hzandbelt@pingidentity.com>
Thread-Topic: [OAUTH-WG] open redirect in rfc6749
Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5JvvlAWAgAABL4CAAAjogIAAAV6AgAABUQA=
Date: Wed, 03 Sep 2014 16:56:12 +0000
Message-ID: <25055629-26A9-478D-AE7A-3C295E3166EE@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>
In-Reply-To: <5407470B.2010904@pingidentity.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:(377454003)(199003)(479174003)(24454002)(51444003)(189002)(66066001)(33656002)(50986999)(79102001)(19580395003)(81542001)(99396002)(83322001)(76482001)(16236675004)(31966008)(19580405001)(19617315012)(46102001)(4396001)(82746002)(20776003)(83072002)(99286002)(15202345003)(110136001)(107046002)(106116001)(2656002)(106356001)(83716003)(74662001)(15975445006)(105586002)(90102001)(587094003)(92566001)(16601075003)(77096002)(85306004)(92726001)(21056001)(77982001)(36756003)(87936001)(85852003)(76176999)(101416001)(64706001)(15395725005)(93886004)(74502001)(86362001)(54356999)(95666004)(80022001)(81342001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB207; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_2505562926A9478DAE7A3C295E3166EEadobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/LB_ueVXqmia04tz0T7gH1wl7KFM
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 16:56:23 -0000

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 the victim.com<http://victim.com/> <http://victim.com<http://victim.com/>>
<http://victim.com<http://victim.com/>>
provider.
I register redirect uri 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/>>.
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