Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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!



Von: jetty-dev <jetty-dev-bounces@xxxxxxxxxxx> Im Auftrag von Greg Wilkins
Gesendet: Montag, 26. Juli 2021 02:56
An: Jetty @ Eclipse developer discussion list <jetty-dev@xxxxxxxxxxx>
Betreff: Re: [jetty-dev] http 400 Ambiguous URI path encoding





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:






On Sun, 25 Jul 2021 at 18:32, <paul.palaszewski@xxxxxxxxxxxxxxx> wrote:



we get that error with the jetty 10.0.6 for the URL /pics/303318_100%25rPET%20Delicontainer_md-12.jpg


OK, the filename contains a % .. but according to my understanding of rfc3986 that’s ok as long as it’s encoded. At least it was for the last 25+ years.

jetty-http/src/main/java/org/eclipse/jetty/http/ line 1210+ does this ambiguous check … I can understand, that you were trying to limit uncommon and bad requests .. but I think, this time you overreacted in the wrong place. For me, this issue has two dimensions:

  1. Did you really want to drop support for % in filenames?
  2. Is it now common sense, that web clients are not allowed anymore to encode things that don’t have to be encoded?? In that regard, I would also doubt that encoding a / should cause a bad request.


It does not improve security – for a security check, you first need to decode the path and then check, if it’s allowed to access it. 99% of those checks should happen within jetty, you should have no problem checking that in the right place. For the remaining 1% it might help to improve the documentation, but I doubt that that will make any difference.


Please don’t hesitate to correct me, if I’m wrong.





BDM Business Data Management GmbH
Ing. Paul Palaszewski
Mobil: +43 650 37 36 030
E-Mail: paul.palaszewski@xxxxxxxxxxxxxxx

Gödelgasse 8/184

1100 Wien
Firmenbuch: FN 242059w, Handelsgericht Wien
UID: ATU57685758

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.


jetty-dev mailing list
To unsubscribe from this list, visit



Back to the top