Re: [OAUTH-WG] open redirect in rfc6749

[John Bradley <[e-mail]>]

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
>