You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jason Rivard <jr...@gmail.com> on 2015/12/18 21:21:12 UTC
Tomcat 8.0.29-30 context root redirect changes break application
I'm not sure if I'm posting this in the right place, but I thought I would
start here. It seems that changes to tomcat 8.0.29-30 partially described
in the following bug break my application, and probably others:
https://bz.apache.org/bugzilla/show_bug.cgi?id=58660
And here is my test application:
https://github.com/jrivard/tomcat-root-redir-test
Behaviors seen:
The issue is that in 8.0.28, a request to the application context
"/context" would result in a redirect to "/context/". This handling was
handed in a way that was invisible to the application code.
In 8.0.29, this request is processed and the application generates a
response.
In 8.0.30, this request is processed by the application, but generates a
302 to "/context/"
8.0.29-30 both break my test application in similar but distinct ways. The
issue is that the application processes the initial request in a filter,
modifies the session object, and then issues a redirect to itself. Because
the JSESSION cookie path is set to "/context/" and not "/context", the
session seen on the subsequent handling of the redirect does not have
access to the same session object as on the first request. In a real
application that depends on similar behavior this breaks the application in
significant ways.
Another way to think of this is that it shouldn't be possible for the
application to access an HttpSession that doesn't match the browser's
session cookie. As of 8.0.30 this implied contract is broken because on
the initial request to the "/context" url, application code has access to
an effectively bogus HttpSession instance.
I understand this can be worked around by setting context parameters
('mapperContextRootRedirectEnabled' for example), but it seems to me the
default behavior shouldn't break existing apps - unless there is a
significant security reason - which I don't think is the case here.
Perhaps this new behavior could be reverted in 8.x and prior, and only
adopted in 9.x.
If I've posted this in the wrong place, or if I should open a bug, please
advise.
Re: Tomcat 8.0.29-30 context root redirect changes break application
Posted by Mark Thomas <ma...@apache.org>.
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 <jr...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 8.0.29-30 context root redirect changes break application
Posted by Jason Rivard <jr...@gmail.com>.
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 <jr...@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. 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.
Should I open a bug for this?
Re: Tomcat 8.0.29-30 context root redirect changes break application
Posted by Mark Thomas <ma...@apache.org>.
On 18 December 2015 20:21:12 GMT+00:00, Jason Rivard <jr...@gmail.com> wrote:
>I'm not sure if I'm posting this in the right place, but I thought I
>would
>start here. It seems that changes to tomcat 8.0.29-30 partially
>described
>in the following bug break my application, and probably others:
>
>https://bz.apache.org/bugzilla/show_bug.cgi?id=58660
>
>And here is my test application:
>
>https://github.com/jrivard/tomcat-root-redir-test
>
>Behaviors seen:
>
>The issue is that in 8.0.28, a request to the application context
>"/context" would result in a redirect to "/context/". This handling
>was
>handed in a way that was invisible to the application code.
>
>In 8.0.29, this request is processed and the application generates a
>response.
>
>In 8.0.30, this request is processed by the application, but generates
>a
>302 to "/context/"
>
>8.0.29-30 both break my test application in similar but distinct ways.
>The
>issue is that the application processes the initial request in a
>filter,
>modifies the session object, and then issues a redirect to itself.
>Because
>the JSESSION cookie path is set to "/context/" and not "/context", the
>session seen on the subsequent handling of the redirect does not have
>access to the same session object as on the first request. In a real
>application that depends on similar behavior this breaks the
>application in
>significant ways.
>
>Another way to think of this is that it shouldn't be possible for the
>application to access an HttpSession that doesn't match the browser's
>session cookie. As of 8.0.30 this implied contract is broken because
>on
>the initial request to the "/context" url, application code has access
>to
>an effectively bogus HttpSession instance.
>
>I understand this can be worked around by setting context parameters
>('mapperContextRootRedirectEnabled' for example), but it seems to me
>the
>default behavior shouldn't break existing apps - unless there is a
>significant security reason - which I don't think is the case here.
>Perhaps this new behavior could be reverted in 8.x and prior, and only
>adopted in 9.x.
>
>If I've posted this in the wrong place, or if I should open a bug,
>please
>advise.
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