Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso <[e-mail]>]

Hi Hans,

I really fail to see how this can be addressed at registration time for cases where registration is unrestricted (namely all the big Providers)

regards

antonio

On Sep 4, 2014, at 9:47 AM, Hans Zandbelt <[e-mail]> wrote:

> Classifying like this must also mean that consent should not be stored until the client is considered (admin) trusted, and admin policy would interfere with user policy.
> 
> IMHO the security consideration would apply only to dynamically registered clients where registration is unrestricted; any other form would involve some form of admin/user approval at registration time, overcoming the concern at authorization time: there's no auto-redirect flow possible for unknown clients.
> 
> Hans.
> 
> On 9/4/14, 9:04 AM, Richer, Justin P. wrote:
>> I think this advice isn't a bad idea, though it's of course up to the AS
>> what an "untrusted" client really is. In practice, this is something
>> that was registered by a non-sysadmin type person, either a dynamically
>> registered client or something available through self-service
>> registration of some type. It's also reasonable that a client, even
>> dynamically registered, would be considered "trusted" if enough time has
>> passed and enough users have used it without things blowing up.
>> 
>>  -- Justin
>> 
>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso <[e-mail]
>> <mailto:[e-mail]>> 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 <[e-mail]
>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>> 
>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote:
>>>>>> 
>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt
>>>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>>>> <[e-mail] <mailto:[e-mail]>
>>>>>>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>> <mailto:[e-mail]>> 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 <[e-mail]
>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>> <mailto:[e-mail]>
>>>>>>>>>>> <mailto:[e-mail]>> 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
>>>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>>>> 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
>>>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>>> 
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> OAuth mailing list
>>>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>>>> <mailto:[e-mail]><mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail]>
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>>> <mailto:[e-mail]>| Ping
>>>>>>>>> Identity
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>>>> [e-mail] <mailto:[e-mail]> |
>>>>>>> Ping Identity
>>>>>> 
>>>>> 
>>>>> --
>>>>> Hans Zandbelt              | Sr. Technical Architect
>>>>> [e-mail] <mailto:[e-mail]>| Ping
>>>>> Identity
>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
> 
> -- 
> Hans Zandbelt              | Sr. Technical Architect
> [e-mail] | Ping Identity