Re: [OAUTH-WG] open redirect in rfc6749

[Phil Hunt <[e-mail]>]

ooops,, that 6819 not 6810

Phil

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



On Sep 3, 2014, at 12:47 PM, Phil Hunt <[e-mail]> wrote:

> 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
>>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth