Re: [OAUTH-WG] open redirect in rfc6749

John Bradley <ve7jtb@ve7jtb.com> Thu, 04 September 2014 05:57 UTC

Return-Path: <ve7jtb@ve7jtb.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 C9F4F1A0680 for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 22:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.145
X-Spam-Level:
X-Spam-Status: No, score=-0.145 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_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 gcHUASem_Unm for <oauth@ietfa.amsl.com>; Wed, 3 Sep 2014 22:57:29 -0700 (PDT)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C531A0697 for <oauth@ietf.org>; Wed, 3 Sep 2014 22:57:28 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id gl10so10973322lab.24 for <oauth@ietf.org>; Wed, 03 Sep 2014 22:57:27 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=+hiE2LhozS54gADdYQ8GWlyQ0kwLXtrpbYk7GAO8bQs=; b=ln76hADd83Msr9oRNEGIhjB9oTwX5VvMUBz29RfHlsshrUE/+SsltfMUvjFL14vMH0 CCtTqjS75VxlsOakvE0Aes6F0vESIRiiLoiZa9xGlO9gGup0jsUDxnbnXlVSqJVdFIYn itgl9c9VeXZrH6YYz0A8a99EglhfCbzlS+8AadqLfxfee2EunK9qywkw0s4tvipGdElQ kk/XfvLW4kxB18KWp8+4HoD2c7Z2OwerhMFUUBRVL8Oq1Enjj0EVF7vqdXqK2TQn3DUj a73QRDcONwtRWK0oG9lgcMapLAHe0n3H9d7OthTkbXm5oRL86zus0u/HZxatHyeIlqyS oYMA==
X-Gm-Message-State: ALoCoQkKsGi6s9/yEdE9fsH1RazDmeIrEXtCT7s3mYNA8+ynuIdCFV7XOVbPjHyDcKZwPyibTUjn
X-Received: by 10.112.28.8 with SMTP id x8mr1975917lbg.104.1409810246885; Wed, 03 Sep 2014 22:57:26 -0700 (PDT)
Received: from [192.168.49.148] (seabed-1-2-ci.cust.versatel.net. [87.213.30.114]) by mx.google.com with ESMTPSA id ld9sm1766172lac.24.2014.09.03.22.57.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 22:57:25 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_C9A396E1-02F0-43C9-8C68-F1C2C8E76232"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com>
Date: Thu, 04 Sep 2014 01:57:04 -0400
Message-Id: <F10CA958-1744-4DE0-8BC8-A96598F866B6@ve7jtb.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> <54075296.9090007@pingidentity.com> <848F15BD-894D-48C6-B901-B5565BDE4C08@adobe.com> <05C25C09-598C-4D7F-A07A-C93DEC17D10B@adobe.com>
To: Antonio Sanso <asanso@adobe.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/sHszR3sXymkHp3YR6vtcUmswNvQ
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: Thu, 04 Sep 2014 05:57:33 -0000

I think that is probably reasonable advice.  

Presenting a dialog to the user also has the beneficial side effect of removing the original referrer from being seen by the party hosting the redirect_uri.  
It is allowing dynamic parameters to be passed in the referrer that is the largest security issue in my opinion.   That is how the AS might be used as a redirector to attack itself.

John B.

On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asanso@adobe.com> wrote:

> hi again *,
> 
> after thinking a bit further IMHO an alternative for the untrusted clients can also be to always present the consent screen (at least once) before any redirect.
> Namely all providers I have seen show the consent screen if all the request parameters are correct and if the user accepts the redirect happens.
> If one of the parameter  (with the exclusion of the client id and redirect uri that are handled differently as for spec) is wrong though the redirect happens without the consent screen being shown..
> 
> WDYT?
> 
> regards
> 
> antonio
> 
> On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asanso@adobe.com> wrote:
> 
>> Well,
>> I do not know if this is only dynamic registration...
>> let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is that dynamic client registration? I do not know… :)
>> 
>> Said that what the other guys think?  :) 
>> Would this deserve some “spec adjustment” ? I mean there is a reason if Google is by choice “violating” the spec right? (I assume to avoid open redirect…)
>> But other implementers do follow the spec hence they have this open redirector… and this is not nice IMHO...
>> 
>> 
>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:
>> 
>>> On 9/3/14, 7:14 PM, Antonio Sanso 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
>>> 
>>> I think your issue is then with the trust model of dynamic client registration; that is left out of scope of the dynreg spec (and the concept is not even part of the core spec), but unless you want everything to be open (which typically would not be the case), then it would involve approval somewhere in the process before the client is registered. Without dynamic client registration that approval is admin based or resource owner based, depending on use case.
>>> 
>>>>> 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…
>>> 
>>> roles can collapse in use cases especially when using dynamic client registration
>>> 
>>>>> 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?
>>> 
>>> because the client and thus the fixed URL are explicitly approved at some point
>>> 
>>> Hans.
>>> 
>>>> 
>>>>> 
>>>>> 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
>> 
>