| Re: [jetty-dev] http 400 Ambiguous URI path encoding |
Hi Greg, Joakim, please don’t understand me wrong - I totally agree with changes reducing potential attack vectors. I was just suprised to get that kind of error report from a customer after applying a sub-version update. And I’ve read the release notes in advance with a feeling to have understood what you wrote. It was a change that required configuration changes which might have been comunicated better. Regarding the arguments … I still can’t loose the feeling, that it’s an attempt to handle security things for people that don’t know how to create secure code. I agree, double-decodes are a problem, but seriously, it’s as any other information encoding + decoding issue: either do it right or you have problems. Doing security checks before decoding the path again can never ever be secure. You already protect the WEB-INF directory and by enforcing path restrictions you protect it even better from additional coded access, but who will protect the application’s admin pages? Log file downloads? Or any other „elegant“ resource access? If it’s not done right in the right place, it’s a lost battle. Thanks for the hint to configure UriCompliance.RFC3986 on HttpConfiguration! I can confirm, that solves the problem for us. We are running an embedded jetty, just had to make sure to configure the standard http connector AND the https connector. Thanks for the excellent support! Paul Von: jetty-dev <jetty-dev-bounces@xxxxxxxxxxx> Im Auftrag von Greg Wilkins Paul, We are definitely not dropping support for % encoding. However, we are moving to a default setup where funky encodings are considered dangerous and will not be allowed through to the application unless the correct mode is configured. In your case, the filename has an encoded % character, which can make an application vulnerable to double decoding attacks if the path is given to an API that does more decoding. In this case, it could be given to getRequestDispatcher, which will then see the encoded % as an encoding escape, so something like /%25%2e/WEB-INF/web.xml might have unintended consequences, as it is not initially protected but will then access a protected resource. Because the request path methods return decoded strings, there are a lot of these cases where decoded reserved characters might be handled incorrectly. Another example is should /foo%2fbar be treated as a special character in the filename "foo/bar" or as the file "bar" in the directory "foo". There is no easy answer. Jetty makes what we think is a safe determination, but with different file systems you can never be sure. Thus for an abundance of caution we are now moving towards blocking ambiguous URIs by default and applications will have to be configured to accept any funky URIs. Note that the servlet specification is considering doing something similar in 6.0: https://github.com/eclipse-ee4j/servlet-api/issues/18 cheers On Sun, 25 Jul 2021 at 18:32, <paul.palaszewski@xxxxxxxxxxxxxxx> wrote:
-- Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com |