Re: [OAUTH-WG] open redirect in rfc6749

[Phil Hunt <[e-mail]>]

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