Hi, On Thu, Sep 24, 2020 at 1:02 PM Nils Breunese <n...@breun.nl> wrote:
> 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? > I remember a similar discussion from a few months ago. Which version of Tomcat do you use ? Please try with the latest in case you use an older one. > > 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
