I think that is probably reasonable advice. Presenting a dialog to the user also has the beneficial side effect of removing the original referrer from being seen by the party hosting the redirect_uri. It is allowing dynamic parameters to be passed in the referrer that is the largest security issue in my opinion. That is how the AS might be used as a redirector to attack itself.
John B. On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asa...@adobe.com> wrote: > hi again *, > > after thinking a bit further IMHO an alternative for the untrusted clients > can also be to always present the consent screen (at least once) before any > redirect. > Namely all providers I have seen show the consent screen if all the request > parameters are correct and if the user accepts the redirect happens. > If one of the parameter (with the exclusion of the client id and redirect > uri that are handled differently as for spec) is wrong though the redirect > happens without the consent screen being shown.. > > WDYT? > > regards > > antonio > > On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asa...@adobe.com> wrote: > >> Well, >> I do not know if this is only dynamic registration... >> let’s talk about real use cases, namely e.g. Google , Facebook , etc.. is >> that dynamic client registration? I do not know… :) >> >> Said that what the other guys think? :) >> Would this deserve some “spec adjustment” ? I mean there is a reason if >> Google is by choice “violating” the spec right? (I assume to avoid open >> redirect…) >> But other implementers do follow the spec hence they have this open >> redirector… and this is not nice IMHO... >> >> >> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote: >> >>> On 9/3/14, 7:14 PM, Antonio Sanso 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 >>> >>> I think your issue is then with the trust model of dynamic client >>> registration; that is left out of scope of the dynreg spec (and the concept >>> is not even part of the core spec), but unless you want everything to be >>> open (which typically would not be the case), then it would involve >>> approval somewhere in the process before the client is registered. Without >>> dynamic client registration that approval is admin based or resource owner >>> based, depending on use case. >>> >>>>> 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… >>> >>> roles can collapse in use cases especially when using dynamic client >>> registration >>> >>>>> 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? >>> >>> because the client and thus the fixed URL are explicitly approved at some >>> point >>> >>> Hans. >>> >>>> >>>>> >>>>> 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 >>>> >>> >>> -- >>> 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
