We have a servlet that acts as a proxy to other URLs from different origins. E.g. via your web app you could get to the Google home page via a URL like:
http://localhost/myapp/proxy/http%3A%2F%2Fwww.google.com%2F Using this URL pattern, we immediately hit the Tomcat "noSlash" restriction (Directory traversal CVE-2007-0450) and in order for our proxy to work we have to set the environment variable org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true. However, enabling this environment variable obviously opens us up to the security vulnerability that CVE-2007-0450 intended to address (being able to navigate to directories protected by the proxy's content restriction). The reason I'm writing is that I'm confused by the fix to CVE-2007-0450. It seems like the fix was "Since Tomcat allows for behavior that's not conformant with the URI spec (i.e. allowing certain encoded characters to be treated as their reserved literal equivalents), disallow those encodings globally". It seems like a more appropriate solution would have been "Do not allow encoded backslashes and slashed to be treated as their literal equivalents". This alternative solution would have: 1) Removed the security vulnerability, and 2) Removed a "feature" that is outside the URI spec It seems like the current solution disallows encoded characters that are allowed by the URI spec in order to maintain behavior that is outside the URI spec. I have more questions on how to respond to this Tomcat behavior, but I'm hoping someone could provide more input on the rationale behind the current fix for CVE-2007-0450 to provide additional context for my other questions. -- Thanks, - Bill Higgins (IBM Rational) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
