Registration requiring a valid email address is not sufficient to stop a "bad" person from registering a client that appears to be perfectly legitimate but is later used as a redirect.
So it is a bit slippery to differentiate good from bad. In general clearing the referrer and fragment from incoming requests is a good practice on redirects to prevent leakage of information across the redirect. The other concern is using the redirect as part of a phishing attack to make the target site look more legitimate. That is a more complicated problem unless you validate every client by looking at them to make sure they are not bad in some way. John B. On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <hzandb...@pingidentity.com> wrote: > Maybe just to clarify my point: where did the client_id in the example that > you gave come from? > > Hans. > > On 9/4/14, 1:58 PM, Hans Zandbelt wrote: >> yes, you are right about the unrestricted client use case; I just got >> caught by the fact that you were talking about *unrestricted* client >> registration all the time (standards-based or not) which deserves extra >> caution whereas Google (and the spec) also provides *restricted* client >> registration the deviation or caution is not needed >> >> Hans. >> >> On 9/4/14, 1:44 PM, Antonio Sanso wrote: >>> 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 >>> >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com | Ping Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
