Julian Reschke <julian.resc...@gmx.de> wrote:

> Am 24.09.2020 um 12:02 schrieb Nils Breunese:
>> 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])
> > ...
> 
> That is very misleading.
> 
> RFC 2396 *extended* path parameters to be applicable to each path
> segment, see
> <https://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.3.3>.
> 
> RFC 3986 further generalized things (see last paragraph of
> <https://www.greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.3>).
> 
> They have not been "dropped".

Ok, interesting. On the Istio issue tracker [0] I got a response saying: “Path 
segments were part of RFC2396, but they are not part of RFC3986 which obsoleted 
it, so they are not part of any active standard for over 15 years.” [0]

If they are still part of current standards, then the argument could be made 
that any system that does path-based access checks should ignore path 
parameters when checking a path, right? Because otherwise it is trivial to get 
around such path-based access restrictions.

Nils.

[0] https://github.com/istio/istio/issues/27409#issuecomment-696784022
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to