[jsr369-experts] decoding of return from getContextPath

From: Edward Burns <edward.burns_at_oracle.com>
Date: Mon, 12 Sep 2016 16:10:39 -0700

>>>>> On Thu, 8 Sep 2016 21:56:52 +1000, Greg Wilkins <gregw_at_webtide.com> said:

GW> I really think we should give Mark the simple life he yearns for :)

Many yearn for it, few enjoy it.

GW> Note that with the spec as it stands, there is no simple call to access to
GW> the decoded normalized deparameterized context path. If the spec is to
GW> remain as is, then we probably need to provide a getContextPathDecoded()
GW> method and encourage its use as a matter of some urgency.

Ok, now this is the real ask, right? I am going to move this to a
separate thread.

GW> I would hazard a guess that most URIs with encoded denormalized
GW> parametrized context paths are created by attackers trying to trick poorly
GW> coded applications that are using context path and never thought that it
GW> could look like /harmless/../ev%69l;nothing=to;see=here

GW> Considering that this has not been a problem for the vast majority of
GW> webapps and that it was only recently reported on tomcat, does indicate
GW> that the impact of reverting to decoded would be small. Changing
GW> containers to decoded has a potential much larger impact even if it
GW> appeared small when tomcat changed. It may have a small functional impact,
GW> but I'm not so sure it's security impact will also be small. It is a
GW> big change for jetty/undertow/etc. to suddenly start exposing all their
GW> deployed base to none normalized client supplied data!

I question the utility of making this change. I think the safest option
is to fix SPEC-163 and add it to the releasenotes for containers that
still do perform decoding in this method.


| edward.burns_at_oracle.com | office: +1 407 458 0017