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. Nils. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
