Simply not true. Phil
@independentid www.independentid.com phil.h...@oracle.com On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asa...@adobe.com> wrote: > hi *, > > my understanding is that there is a rough consensus that if an OAuth Provider > follows rfc6749 verbatim will end up having an open redirector. > My next question would be now, is there anything we can do to raise some > awareness about this issue? > > regards > > antonio > > 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"... >> >> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
