Re: [OAUTH-WG] open redirect in rfc6749

Bill Burke <bburke@redhat.com> Wed, 03 September 2014 16:10 UTC

Return-Path: <bburke@redhat.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 5D2341A0AE0 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 09:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.57
X-Spam-Level:
X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 633ZTvqo1VrW for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 09:10:26 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFD01A0691 for <oauth@ietf.org>; Wed, 3 Sep 2014 09:10:26 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s83GAORt029460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <oauth@ietf.org>; Wed, 3 Sep 2014 12:10:25 -0400
Received: from [10.10.63.182] (vpn-63-182.rdu2.redhat.com [10.10.63.182]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83GAOIq011217 for <oauth@ietf.org>; Wed, 3 Sep 2014 12:10:24 -0400
Message-ID: <54073D6F.6070203@redhat.com>
Date: Wed, 03 Sep 2014 12:10:23 -0400
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com>
In-Reply-To: <756EEB25-89E8-4445-9DA0-5522787D51AB@adobe.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/9TsflOES3dgs4lMkmpZBIjp7_jE
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:10:29 -0000

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>
> 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
>
>
> _______________________________________________
> 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