Re: [OAUTH-WG] open redirect in rfc6749

[Antonio Sanso <[e-mail]>]

On Sep 3, 2014, at 6: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.

the redirect uri is indeed valid. The wrong parameter is the scope.

So if the attacker is the person that registers the app and register as redirect uri attacker.com<http://attacker.com> he can redirect anybody to attacker.com<http://attacker.com> levering the provider website uri…



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


--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com<http://bill.burkecentral.com/>

_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth