Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso <[e-mail]>]

hi Phil,
can you point out the relative paragraph that covers this specific case in RFC6819?
On Sep 3, 2014, at 9:23 PM, Phil Hunt <[e-mail]> wrote:

> I do not believe this is a flaw specific to 6749. The flaw if any is within HTTP itself (RFC7230). Covert redirect is a well known problem. There are extensive recommendations that prevent this covered in 6749 and 6819.
> 
> There is no protocol fix that OAuth can make since it is a trait or feature of HTTP.
> 
> Instead we’ve made security recommendations which are the appropriate response to this issue. Further we published 6819 that provides further guidance.
> 
> Phil
> 
> @independentid
> www.independentid.com
> [e-mail]
> 
> 
> 
> On Sep 3, 2014, at 11:42 AM, Hans Zandbelt <[e-mail]> wrote:
> 
>> 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
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>