Re: [jetty-dev] http 400 Ambiguous URI path encoding

[Greg Wilkins <gregw@xxxxxxxxxxx>]

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:

Hi,

 

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/HttpURI.java 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.

 

Regards,

Paul

 

BDM Business Data Management GmbH
Ing. Paul Palaszewski
Geschäftsführer
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
jetty-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-dev

--

Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com