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. > Clearly there is scope for more education and documentation on this > issue. The (very) short version is when using a reverse proxy in front > of Tomcat: > 1. Ideally don't rely on the reverse proxy to limit access to resources > on Tomcat. Secure Tomcat as if everything was accessible. We currently have a policy to not secure the applications themselves, 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. > 2. If you can't do 1, use mod_jk or the ISAPI redirector as they should > map URIs to proxy targets using the same mapping rules as Tomcat (and if > they don't we'll almost certainly treat that as a security issue). Istio on Kubernetes uses Envoy as a proxy. I don’t think Envoy provides something like this. > 3. If you can't do 1 or 2 you can try and block potentially malicious > URIs in the reverse proxy but this is hard (need to think about "/../" > and "/./" sequences, path parameters, %nn encoding and combinations of > all three. > > If you get as far as option 3, you really need to go back and > re-consider option 1 or 2 as the chances of getting 3 100% right are slim. AFAIK Envoy does normalize path traversal sequences like /../, but path parameters can break these sequences, and Envoy currently doesn’t ignore those, like the /v1/..;color=red/internal/secrets example. Nils. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
