Re: [OAUTH-WG] open redirect in rfc6749

[John Bradley <[e-mail]>]

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.

John B.

On Sep 3, 2014, at 12:10 PM, Bill Burke <[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>
>> provider.
>> I register redirect uri 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>.
>> 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