Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt <[e-mail]>]

fine, you're talking security considerations about untrusted clients; 
that's a different use case than the protocol flaw reason why Google 
would not do rfc6749 as written

Hans.

On 9/3/14, 7:52 PM, John Bradley wrote:
> I agree that the error case where there is no UI is the problem, as it can be used inside a Iframe.
>
> However error responses are generally useful.
>
> OAuth core is silent on how redirect_uri are registered and if they are verified.
>
> Dynamic registration should warn about OAuth errors to redirect_uri from untrusted clients.
>
> For other registration methods we should update the RFC.
>
> John B.
>
>
>
>
> Sent from my iPhone
>
>> On Sep 3, 2014, at 7:14 PM, Antonio Sanso <[e-mail]> wrote:
>>
>>
>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <[e-mail]> wrote:
>>>
>>> Is your concern clients that were registered using dynamic client registration?
>>
>> yes
>>
>>>
>>> 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…
>>
>>
>>> 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?
>>
>>>
>>> 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
>>

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