Re: [OAUTH-WG] open redirect in rfc6749

[Hans Zandbelt <[e-mail]>]

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?

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]>> 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]>> 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 the victim.com <http://victim.com>
>>>> <http://victim.com>
>>>> provider.
>>>> I register redirect uri 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>.
>>>> 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]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[e-mail] | Ping Identity