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 <asa...@adobe.com> wrote: > > >> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt <hzandb...@pingidentity.com> 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 <hzandb...@pingidentity.com >>> <mailto:hzandb...@pingidentity.com>> 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 <ve7...@ve7jtb.com >>>>> <mailto:ve7...@ve7jtb.com> >>>>> <mailto:ve7...@ve7jtb.com>> 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 <bbu...@redhat.com >>>>>> <mailto:bbu...@redhat.com> >>>>>> <mailto: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 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 >>>>>>>> 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 <mailto:OAuth@ietf.org> >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> -- >>>> Hans Zandbelt | Sr. Technical Architect >>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| Ping >>>> Identity >> >> -- >> Hans Zandbelt | Sr. Technical Architect >> hzandb...@pingidentity.com | Ping Identity >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
