hi Hans On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote:
> I am convinced about the issue in the use case Antonio provided but I hope > not to close the door on returning errors to known and trusted clients. Not > sure anymore if that's possible though because the distinction can't be > "registered"… an alternative is to show always the consent screen (at least once if the client id/redirect_uri is valid and accept the app) even if the scope or any other parameter is not valid before to redirect to the redirect uri. regards antonio > > Hans. > > On 9/4/14, 3:01 PM, Antonio Sanso wrote: >> hi Bill >> On Sep 4, 2014, at 2:52 PM, Bill Burke <bbu...@redhat.com> wrote: >> >>> FWIW, Antonio convinced me and I'm going to change this in our IDM project. >>> Thanks Antonio. What convinced me was that the user is probably expecting >>> a login screen. Since there is this expectation, it might make it a little >>> easier for the attacker to convince the user that a spoofed login screen is >>> real. I know this issue can only happen with unrestricted registration, >>> but, IMO, this proposed change doesn't really have much of an effect on >>> usability and is even backward compatible with the current RFC. >>> >>> Wouldn't it better though to never do a redirect on an invalid request and >>> just display an error page? >> >> thanks for sharing your thoughts :). Display an error 400 is what Google >> does :) >> >> regards >> >> antonio >> >>> >>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>> Hi Hans, >>>> >>>> I really fail to see how this can be addressed at registration time for >>>> cases where registration is unrestricted (namely all the big Providers) >>>> >>>> regards >>>> >>>> antonio >>>> >>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt <hzandb...@pingidentity.com> >>>> wrote: >>>> >>>>> Classifying like this must also mean that consent should not be stored >>>>> until the client is considered (admin) trusted, and admin policy would >>>>> interfere with user policy. >>>>> >>>>> IMHO the security consideration would apply only to dynamically >>>>> registered clients where registration is unrestricted; any other form >>>>> would involve some form of admin/user approval at registration time, >>>>> overcoming the concern at authorization time: there's no auto-redirect >>>>> flow possible for unknown clients. >>>>> >>>>> Hans. >>>>> >>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>> I think this advice isn't a bad idea, though it's of course up to the AS >>>>>> what an "untrusted" client really is. In practice, this is something >>>>>> that was registered by a non-sysadmin type person, either a dynamically >>>>>> registered client or something available through self-service >>>>>> registration of some type. It's also reasonable that a client, even >>>>>> dynamically registered, would be considered "trusted" if enough time has >>>>>> passed and enough users have used it without things blowing up. >>>>>> >>>>>> -- Justin >>>>>> >>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asa...@adobe.com >>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>>> <mailto: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 <mailto: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> >>>>>>>>>>>> <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> >>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>> <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://thevictim.com/> >>>>>>>>>>>>>>>>> <http://victim.com/><http://victim.com <http://victim.com/> >>>>>>>>>>>>>>>>> <http://victim.com/>> >>>>>>>>>>>>>>>>> <http://victim.com <http://victim.com/> <http://victim.com/>> >>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>> I register redirect uriattacker.com <http://uriattacker.com/> >>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.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/>> <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 <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>> <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> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>>>>>> Identity >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> | >>>>>>>>>>> Ping Identity >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>> Identity >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 | Ping Identity >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
