Hello, I recently learned that when a server that supports path parameters [0] — like Tomcat (I found Jetty also does) — is run behind a reverse proxy that does path-based access control checks and does not support path parameters, your combined setup could be vulnerable.
Consider this setup: 1. A Tomcat application without access restrictions 2. An reverse proxy that only allows requests to /v1/* on the Tomcat application. I’ve used Envoy on Kubernetes, configured via Istio’s Role-Based Access Control (RBAC), but also observed this issue with other proxies. Now I send a request for /v1/..;color=red/internal/secret to the proxy. - 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]) - Tomcat parses ;color=red as a path parameter, resolves the rest of the path to /v1/../internal/secret and consequently serves /internal/secret - I’m pretty sure that whoever configured that RBAC policy did not want this to be possible Note that: - The client can request any URL on the Tomcat server via this path traversal attack. - This also works with ‘empty’ path parameters, e.g. /v1/..;/internal/secret - The URL doesn’t necessarily need to contain ‘..’ for naughtiness to be possible. When access to /public/secret would be restricted by the proxy, but other /public/* paths would be allowed, then an attacker would still be able to get the contents of /public/secret by requesting /public;/secret The fact that different servers handle paths with path parameters differently seems to be known [2], but especially setups in which reverse proxies don’t support path parameters, but the servers behind them do, seems risky. Would it be reasonable to create a ticket with a feature request for a flag to disable path parameter support in Tomcat? Or an even more secure suggestion: make path parameter support an opt-in feature, because it was dropped from the URI standard in 1998 and can make setups like I described vulnerable? Thanks, Nils. [0] RFC 1738 https://tools.ietf.org/html/rfc1738 <https://tools.ietf.org/html/rfc1738> (1994) and RFC 1808 https://tools.ietf.org/html/rfc1808 <https://tools.ietf.org/html/rfc1808> (1995). [1] RFC 2396 G.4. Modifications from RFC 1808 https://tools.ietf.org/html/rfc2396 <https://tools.ietf.org/html/rfc2396> (1998). Path parameters are also absent in RFC 3986 https://tools.ietf.org/html/rfc3986 <https://tools.ietf.org/html/rfc3986> (2005). [2] https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf <https://i.blackhat.com/us-18/Wed-August-8/us-18-Orange-Tsai-Breaking-Parser-Logic-Take-Your-Path-Normalization-Off-And-Pop-0days-Out-2.pdf> slides 41 and further
