Nils, 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.
But as a proxy, it should be forwarding the URLs as-is and may have different normalization behavior in that case. 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. >> 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 Wow. > , 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. >> 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. Again, there might be a difference in normalization when it's being used as a proxy. Tomcat will only use path parameters in the final segment of a URL e.g. https://www.example.com/app/servlet;jsessionid=ABCD1234?q=search Assuming your application doesn't use path-parameters for anything else, you should be able to detect and block any non-terminal path-segment which contains a parameter and simply refuse the request with 400 or something similar. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
