On Sep 15, 2014, at 9:41 PM, Phil Hunt <[email protected]> wrote: hi Phil
> Simply not true. why do you think so ? regards antonio > > Phil > > @independentid > www.independentid.com > [email protected] > > > > On Sep 15, 2014, at 12:10 PM, Antonio Sanso <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[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 >>>>>> >>>>> >>>>> -- >>>>> Bill Burke >>>>> JBoss, a division of Red Hat >>>>> http://bill.burkecentral.com >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
