Re: [OAUTH-WG] open redirect in rfc6749

[Phil Hunt <[e-mail]>]

in RFC6810, see section 3.5 and 4.1.5. 

Phil

@independentid
www.independentid.com
[e-mail]



On Sep 3, 2014, at 12:36 PM, Antonio Sanso <[e-mail]> wrote:

> 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
>> 
>