On 4/27/2017 2:27 PM, Mark Thomas wrote:
On 27/04/17 17:23, Stephen Crawford wrote:
Hello All,
We are running Tomcat 8.5.13 on Linux, mostly as a container for
Geoserver. We have a few apps (in Flash!) that have been running fine
untouched for at least six years but stopped working a few weeks ago. I
believe the issue appeared before we upgraded from Tomcat 6.0.24,
probably after a security patch. For that and other reasons we
upgraded, but the problem persists.
I believe the problem is that a "loose" URL encoding that was previously
being allowed to go through is now being stopped and returning a code
400 Bad Request. I narrowed down the culprit to this portion of the xml
filter at the end of the url string:
<PropertyIsLike wildCard="*" escape="\" singleChar="?">
which the browser encodes as:
%3CPropertyIsLike%20wildCard=%22*%22%20escape=%22\%22%20singleChar=%22?%22%3E
Note that the "*", "\" and "?" remain not encoded. If I replace
(encode) these the request is sent on through.
My question: can I configure Tomcat to return to the the previous
behavior of allowing this request? I cannot change the Flash apps
I assume that that string is part of the query string. If it was part of
the path I'd be amazed if it ever worked. (I'd expect the '?' to be
treated as the start of the query string.)
The root cause of the tightening of the restrictions was CVE-2016-6816.
Looking at the code, the '*' and the '?' should be OK. It is the '\'
that is problematic.
(Note: If the specification for the query string was enforced, '?' would
be problematic as well.)
8.5.x and earlier allow the restrictions for some invalid characters to
be lifted. '\' is not among them.
Generally '\' is problematic because it will be treated as a path
separator on some platforms but not on others. That has led to security
vulnerabilities in the past when attackers put \..\ in the URL to bypass
security restrictions. I'm a little surprised Tomcat allowed it before
CVE-2016-6816 was fixed but digging into the code we have a check for
that in the path (which confirms my suspicion the string in question is
in the query string).
To get to your question, it is not currently possible to configure
Tomcat to allow this.
Possible options are:
1. Find a way to fix the flash app.
2. Convince the Tomcat developers to validate the path and query string
segments separately and be (optionally) more lenient with the query string.
3. Use a reverse proxy in front of Tomcat and encode the query string
properly before passing it to Tomcat.
1. is the 'right' solution. After all the client is not specification
compliant.
2. is unlikely. More sophisticated validation will have a performance
impact and the trend has been for Tomcat to be more stringent with
respect to spec compliance, not less.
3. is likely the simplest. Until the proxies implement more stringent
rules for much the same reason as Tomcat did (CVE-2016-6816).
I suspect this isn.t what you wanted to hear. Sorry.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Thanks for such a thorough answer; not what I wanted to hear but mostly
expected. Seven years was a pretty good run. Now to see if the client
has the $$ for the HTML5 version....
--
Stephen Crawford
Center for Environmental Informatics
The Pennsylvania State University
src...@psu.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
