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
