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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>> >>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>> <[email protected] <mailto:[email protected]>> 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 >>>>>>>> <[email protected] <mailto:[email protected]> >>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected]>> 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 <[email protected] >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected]>> 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 >>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>> 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 >>>>>>>>>>>> [email protected] <mailto:[email protected]> <mailto:[email protected]> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OAuth mailing list >>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>> <mailto:[email protected]><mailto:[email protected]> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> [email protected] <mailto:[email protected]> <mailto:[email protected]> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>> <mailto:[email protected]>| Ping >>>>>>>>> Identity >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> [email protected] <mailto:[email protected]> | >>>>>>> Ping Identity >>>>>> >>>>> >>>>> -- >>>>> Hans Zandbelt | Sr. Technical Architect >>>>> [email protected] <mailto:[email protected]>| Ping >>>>> Identity >>>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >> > > -- > Hans Zandbelt | Sr. Technical Architect > [email protected] | Ping Identity _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
