I registered via the Google Developers Console [0] :) [0] https://console.developers.google.com/project On Sep 4, 2014, at 2:09 PM, Hans Zandbelt <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[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 -- Hans Zandbelt | Sr. Technical Architect [email protected] | Ping Identity -- Hans Zandbelt | Sr. Technical Architect [email protected]<mailto:[email protected]> | Ping Identity
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
