| Re: [jetty-dev] http 400 Ambiguous URI path encoding |
_______________________________________________Hi Greg, Joakim,
In 2021 I asked about a change in path validation, now with 12.0.8 I have to ask a similar question again.
You changed the UriCompliance check to follow servlet spec 6 rules more strictly, including any kind of \ either as \ or as %5c is suspicious. I would have expected, that UriComplance.LEGACY or UriCompliance.RFC3986 would help, but they don’t. I checked the sources but I could not find any way to disable that check.
We encode business keys as path elements and some of them may even contain \, others may contain other path separators that we \-escape (like in the programming language c). I’m not in the position to convince my customers not to use those chars in their business. I’ve looked into replacing the \ encoding with a _ encoding or a . encoding (any other special char would get this encoding char up front), but that does not provide a way to encode \, because by the rules I can’t have that at all. I would need to do some kind of url encoding that’s not a correct url encoding (because otherwise browsers would change it because they think they know what it means) = an encoding for an encoding for … it gets ugly.
I’m not sure, if you/others consider those UriCompliance checks now as improved or broken. But could you please add some way, that I can hardcoded call in out custom jetty to disable that check?
Kind regards,
Paul Palaszewski
Von: jetty-dev <jetty-dev-bounces@xxxxxxxxxxx> Im Auftrag von paul.palaszewski@xxxxxxxxxxxxxxx
Gesendet: Montag, 26. Juli 2021 09:24
An: 'Jetty @ Eclipse developer discussion list' <jetty-dev@xxxxxxxxxxx>
Betreff: 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
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
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:
- Did you really want to drop support for % in filenames?
- 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/1841100 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
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-dev