Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt <[e-mail]>]

Maybe just to clarify my point: where did the client_id in the example 
that you gave come from?

Hans.

On 9/4/14, 1:58 PM, Hans Zandbelt wrote:
> yes, you are right about the unrestricted client use case; I just got
> caught by the fact that you were talking about *unrestricted* client
> registration all the time (standards-based or not) which deserves extra
> caution whereas Google (and the spec) also provides *restricted* client
> registration the deviation or caution is not needed
>
> Hans.
>
> On 9/4/14, 1:44 PM, Antonio Sanso wrote:
>> hi Hans
>>
>> On Sep 4, 2014, at 10:58 AM, Hans Zandbelt
>> <[e-mail]> wrote:
>>
>>> Agreed, I see you point about the big providers using exactly the
>>> unrestricted flow for which the trust model (by definition) is out of
>>> scope of the spec. This may be the reason for the implemented
>>> behavior indeed and a security consideration is a good idea for other
>>> deployments; there's not much more that can be done.
>>>
>>> But Google also provides explicit registration for API clients (which
>>> is where my mind was):
>>> https://developers.google.com/accounts/docs/OAuth2 (step 1)
>>> and they would not need to deviate from the spec for that, nor would
>>> the spec need to change
>>
>> I do really struggle to understand your point here :) (at least the
>> "nor would the spec need to change part" :)).
>>
>> Probably I need to explain myself better.
>> Since Google is “safe” (due the “deviation” from the spec) I would
>> take Google as example here (I could point out open redirector in the
>> wild to proof my point but I will not do…)
>>
>> Let’s start from scratch…
>>
>> If Google would have something like
>> http://www.google.com?goto=attacker.com this is without any doubt an
>> open redirector… see  also OWASP 10 [0].
>>
>> Now if Google would have implemented the spec rfc6749 verbatim
>> something like
>>
>> https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
>>
>>
>> would have redirect to http://attacker.com.
>>
>> So why this is not an open redirect ? :)
>>
>> Now maybe we are saying the same thing but I felt like better explain
>> my point :)
>>
>> regards
>>
>> antonio
>>
>> [0]
>> https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards
>>
>>
>>
>>>
>>> Hans.
>>>
>>> On 9/4/14, 9:50 AM, Antonio Sanso wrote:
>>>> 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
>>>>
>>>
>>> --
>>> Hans Zandbelt              | Sr. Technical Architect
>>> [e-mail] | Ping Identity
>>
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[e-mail] | Ping Identity