[OAUTH-WG] open redirect in rfc6749

Antonio Sanso <asanso@adobe.com> Wed, 03 September 2014 15:44 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 9C2811A0ACE for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 08:44:08 -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 xpznUz5t2458 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 08:44:05 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05C41A0B01 for <oauth@ietf.org>; Wed, 3 Sep 2014 08:43:20 -0700 (PDT)
Received: from CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) by CO1PR02MB206.namprd02.prod.outlook.com (10.242.165.144) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Wed, 3 Sep 2014 15:43:18 +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 15:43:18 +0000
From: Antonio Sanso <asanso@adobe.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: open redirect in rfc6749
Thread-Index: AQHPx43Iqm72AKs/tk+aoXIbGajW5A==
Date: Wed, 03 Sep 2014 15:43:17 +0000
Message-ID: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.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:(199003)(189002)(19617315012)(90102001)(16601075003)(85306004)(74662001)(77982001)(92566001)(95666004)(79102001)(83322001)(83072002)(85852003)(46102001)(99396002)(15202345003)(64706001)(110136001)(92726001)(15395725005)(33656002)(66066001)(21056001)(107886001)(105586002)(54356999)(36756003)(86362001)(74502001)(2351001)(31966008)(15975445006)(82746002)(16236675004)(106356001)(2656002)(229853001)(83716003)(4396001)(50986999)(76482001)(106116001)(81542001)(101416001)(19580395003)(80022001)(20776003)(77096002)(87936001)(107046002)(2501002)(99286002)(81342001)(104396001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR02MB206; H:CO1PR02MB206.namprd02.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_756EEB2589E844459DA05522787D51ABadobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/gIuIrxeXudRBg8L6RYGDElxrc4s
Subject: [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 15:44:08 -0000

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, per Appendix 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> provider.
I register redirect uri 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>.
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