Nils, On 9/24/20 13:29, Nils Breunese wrote: > Christopher Schultz <ch...@christopherschultz.net> wrote: > >> On 9/24/20 07:46, Nils Breunese wrote: >>> Mark Thomas <ma...@apache.org> wrote: >>> >>>> On 24/09/2020 11:02, Nils Breunese wrote: >>>> >>>> <snip> >>>> >>>>> - Envoy allows the request based on the /v1/* rule, because it >>>>> does not support path parameters, because they are not part of >>>>> any recent standard (RFC 2396 dropped them in 1998 [1]) >>>> >>>> Envoy does support path parameters and is correctly doing so in this >>>> case as an HTTP reverse proxy by passing them through to the back-end. >>>> From an HTTP perspective "/bar" and "/foo/..;a=1/bar" are completely >>>> different URIs. Envoy's behaviour as an HTTP reverse proxy is correct. >>> >>> I wasn’t suggesting that Envoy should modify the URL that it passes >>> to the backend, but when doing its path-based access checks, I think >>> it should ignore path parameters and normalize the path, otherwise it >>> is trivial to get around these access restrictions. >>> >>> When only allowing /v1/* Envoy won’t allow /v1/../internal/secrets, >>> because it normalises that to /internal/secrets and then sees it >>> doesn’t mach the access rule, but it will allow >>> /v1/..;color=red/internal/secrets because there is nothing to >>> normalize as far as it’s concerned. >> That seems inconsistent to me. If you remove the path parameter, you get >> /v1/../internal/secrets which would be normalized to /internal/secrets >> and therefore not allowed. > > I’m not sure what you think is inconsistent. That is indeed what would happen > if Envoy would ignore the path parameter when doing the check, but it doesn’t > do that, because it doesn’t understand path parameters. > >> But as a proxy, it should be forwarding the URLs as-is and may have >> different normalization behavior in that case. > > I guess we were indeed operating under the assumption that URLs are URLs, but > apparently different systems deal with them differently, which can cause > unexpected behaviour and even security vulnerabilities. This was news to us. > >> Honestly, if you want Envoy to enforce this kind of protection, it is >> Envoy you will need to configure properly. For example, if >> path-parameters are not used in your environment, consider simply >> rejecting any request that contains one and then your security layer >> will work as (otherwise) expected. > > This is indeed the workaround we decided to go with, but it feels weird that > we had to do this. I expect there are many other insecure setups around > because of the different ways URLs are handled by various systems. > > If Envoy would ‘understand’ path parameters and that they should be > considered insignificant when doing path-based access checks, we would have > been fine. But it seems Envoy and Tomcat don’t agree on whether path > parameters are a thing or not. We’ll also talk to the Envoy people again > about this. > >>> We currently have a policy to not secure the applications themselves >> >> Wow. > > Ok, a little nuance: when it comes to path-based access restrictions. > >>> , but handle this via generic access controls that can be centrally >>> audited and configured independently of what language or server is >>> used to implement the application. >> Okay. It looks like those generic access controls need a significant >> upgrade, then. > > Well yeah, it’s not like Envoy is a super niche proxy. We also found > the exact same issue in two other proxies in our network by the way. > Any proxy that does not consider path parameters when doing > path-based access control will have this issue when combined with a > server that does support them. This statement can be generalized to the following:
"When HTTP proxies and origin-servers disagree about how to process requests (specifically their URLs), Bad Things can happen." I would expect most proxies to behave the way that Envoy evidently does: pass-through the URL in the request to the origin server. It's kind of a requirement of the HTTP spec(s). On the other hand, if you are applying a security-constraint at the proxy layer, I would expect that the server would at least explain how path-parameters are handled/normalized/removed/resolved/etc. Either Envoy doesn't publish that information, or you didn't read that section of the manual. There may even be a setting like normalize-URLs-to-be-proxied-for-authorization-checks or something like that. Or maybe not. Tomcat has a suite of settings in that same vein with all the defaults being (a) (reasonably) spec-compliant and (b) safe. But again, if the proxy and origin disagree, you'd better know the details and plan for them. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
