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 <bbu...@redhat.com> 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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
