hi Hans On Sep 4, 2014, at 10:58 AM, Hans Zandbelt <hzandb...@pingidentity.com> wrote:
> Agreed, I see you point about the big providers using exactly the > unrestricted flow for which the trust model (by definition) is out of scope > of the spec. This may be the reason for the implemented behavior indeed and a > security consideration is a good idea for other deployments; there's not much > more that can be done. > > But Google also provides explicit registration for API clients (which is > where my mind was): > https://developers.google.com/accounts/docs/OAuth2 (step 1) > and they would not need to deviate from the spec for that, nor would the spec > need to change I do really struggle to understand your point here :) (at least the "nor would the spec need to change part" :)). Probably I need to explain myself better. Since Google is “safe” (due the “deviation” from the spec) I would take Google as example here (I could point out open redirector in the wild to proof my point but I will not do…) Let’s start from scratch… If Google would have something like http://www.google.com?goto=attacker.com this is without any doubt an open redirector… see also OWASP 10 [0]. Now if Google would have implemented the spec rfc6749 verbatim something like https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=788732372078.apps.googleusercontent.com&scope=WRONG_SCOPE&redirect_uri=http://attacker.com would have redirect to http://attacker.com. So why this is not an open redirect ? :) Now maybe we are saying the same thing but I felt like better explain my point :) regards antonio [0] https://www.owasp.org/index.php/Top_10_2010-A10-Unvalidated_Redirects_and_Forwards > > Hans. > > On 9/4/14, 9: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 >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
