2016-06-15 12:31 GMT+02:00 Mark Thomas <ma...@apache.org>: > Hi all, > > A problem[1] with the default for sessionCookiePathUsesTrailingSlash has > cropped up via $work and after some research I wanted to discuss whether > the default should be changed. > > The default for sessionCookiePathUsesTrailingSlash is true to work > around a potential security issue in a number of browsers. I did a quick > test before writing this e-mail and it appears that IE, Edge and Safari > are affected. Together they represent approximately 42% of the current > browser market share[2]. > > The security issue is that for a cookie path of '/foo', these browsers > include in the cookie when sending requests to '/foobar'. Tomcat > therefore introduced sessionCookiePathUsesTrailingSlash which adds a '/' > to the cookie path so '/foo' becomes '/foo/' since no user agent will > include this in a request to '/foobar'. > > However, this can cause problems. To summarise [1], we have: > A user request for '/foo' > A security enforcing filter that uses cookies mapped to '/*' > A web application with a controller servlet mapped to '/*' > > The sequence of events is: > - Tomcat receives the request for '/foo' > - Because of the servlet mapped to '/*', Tomcat does not redirect > this to '/foo/' > - The security filter creates a session cookie (path '/foo/') > - The security filter performs authentication which includes > additional requests from the client to '/foo' > - The security filter rejects the authentication because the > subsequent requests do not include the cookie because the path > does not match > > RFC 6265, section 4.1.2.4 is clear that cookies with a path of '/foo' > should not be included with requests for '/foobar'. However that same > section also makes clear that cookie paths should not be relied upon for > security. It references RFC 6265 section 8 which provides several > reasons for this in addition to the broken behaviour described above. > > Given the problems caused by the current default for > sessionCookiePathUsesTrailingSlash and the warnings in RFC 6265 > regarding relying on cookie paths for security, I would like to propose > the following changes: > 1. Change the default for sessionCookiePathUsesTrailingSlash to false. > 2. Add some explanatory notes to the documentation for > sessionCookiePathUsesTrailingSlash that makes clear that the setting > is: > a) intended to work around broken browser behaviour > b) while it closes one security hole, others are likely to remain > and reference RFC 6265 section 8. > > Thoughts? > > +1
Rémy