On 18/12/2015 21:47, Jason Rivard wrote: > On Fri, Dec 18, 2015 at 4:36 PM, Mark Thomas <ma...@apache.org> wrote: > >> On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard <jriv...@gmail.com> >> wrote: > > [snip] >> > >> You can use sessionCookiePathUsesTrailingSlash on the Context to fix the >> session problem but be aware of the security risks if you have contexts >> with common prefixes. >> >> We might need to rethink the defaults of these inter-related Context >> options to get a set that it self-consistent and secure. >> >> Mark > > > Yes, I'm pretty sure that would fix the problem as well, but has the > security risks you mention.
Those risks are actually pretty low and specific to particular environments. It is unlikely you would be affected. a) It requires a malicious application be installed alongside the target application. b) If the target application is installed at /path then the malicious application needs to be installed at /pathXXXX. Installing untrusted applications is rare. It happens more often in hosting environments. In any circumstance where untrusted apps were being installed I'd expect there to be one Tomcat instance per app to isolate app from each other so one app can't DoS other apps by, for example, consuming all the memory. In addition, it is easy to ensure that paths for untrusted apps don't overlap paths for trusted apps. > From my perspective, this is more an issue > about the default behavior changing. My existing binary app releases are > broken when a newer version of tomcat is used - and that shouldn't happen. Generally, I agree with you although there are some exceptions. The default is likely to be changed back to the original behaviour in the next release. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
