Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt <[e-mail]>]

Is your concern clients that were registered using dynamic client 
registration?

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 
and the negative case is returning an error to that same URL.

I fail to see the open redirect.

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]>> 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]>> 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]>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [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
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> [e-mail] <mailto:[e-mail]>| Ping
>> Identity
>

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