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. That the back-end may map URIs to resources in such a way that both those URIs result in the same resource being served is solely a concern for the back-end and entirely transparent to the HTTP reverse proxy. The current RFC for URIs (3986) continues to make reference to parameters within segments and using ';' as a delimiter for them. See the final paragraph of section 3.3. The reference in section D.2 to obsolete rules is a simplification of the grammar, not a removal of features. > - 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 Then whoever configured the role-based access control shouldn't have assumed that the reverse proxy used the same rules for URI to proxy target mapping as the back-end used for mapping URIs to resources. They either needed to ensure that Envoy was configured to map proxied requests using the same mapping rules as the Servlet spec (I'd be surprised if such a configuration setting was available) or to configure the access control in the back-end. This is a common error. Since mod_jk and the the ISAPI redirector are provided by the Apache Tomcat project it is reasonable for users to assume that they map URIs to proxy targets using the same rules as the Servlet spec does for URIs to resources. Where differences have been found over the years, CVEs have been allocated. If a generic HTTP reverse proxy (e.g. mod_proxy_http) is used then the mapping of URIs to proxy targets is going to be HTTP based, not Servlet based. That said, I understand that the httpd team is looking at implementation a configuration option for mod_proxy that would cause it to use Servlet mapping rules to map URIs to proxy targets. <snip/> > Would it be reasonable to create a ticket with a feature request for a flag > to disable path parameter support in Tomcat? No. Support for path parameters is an explicit requirement of the Servlet specification. (Aside: 1. While the Servlet spec language isn't aligned with RFC 3986 the expert group has made it clear that the intention is that references to "path parameter" should be read as "parameter associated with any segment of the URI". 2. Whether the Servlet spec should still be supporting URI re-writing as a method of session tracking is debatable. https://github.com/eclipse-ee4j/servlet-api/issues is the place to raise the issue of removing it. ) > 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? No, because it hasn't been dropped from the URI standard and it is a supporting path parameters is a mandatory requirement of the Servlet spec. 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. 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). 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. Finally, it is probably worth setting out what are the mapping rules defined by the Servlet spec as the definition is very much implicit rather than explicit. 1. Remove all path parameters 2. Collapse all "//" to "/" 3. Remove "/./" segments 4. Remove "/xxx/../" segments (If a leading "/../" remains that is an error) Then Tomcat will map the resulting URI to a resource as per chapter 12 of the Servlet 4.0 spec. mod_jk (and ISAPI) will map the resulting URI to the proxy targets as per the docs http://tomcat.apache.org/connectors-doc/reference/uriworkermap.html Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
