Bug 48913 - Request.changeSessionId adds a second Set-Cookie JSESSIONID
Summary: Request.changeSessionId adds a second Set-Cookie JSESSIONID
Status: RESOLVED DUPLICATE of bug 49158
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 6.0.24
Hardware: All All
: P2 regression (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-15 08:05 UTC by Stephan Zlatarev
Modified: 2010-04-20 13:17 UTC (History)
1 user (show)



Attachments
Proposed patch to remove previously set session cookies (3.38 KB, patch)
2010-03-30 23:06 UTC, Mark Thomas
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stephan Zlatarev 2010-03-15 08:05:45 UTC
The protection mechanism against session fixation attacks available in Tomcat 6.0.24 has the problem that if a Valve or a custom Authenticator implementation enforces creation of an HTTP session for a request and the JSESSIONID is created before the authenticator registers the session and it is required to change the session id (which is the default behavior) then instead of changing the session id a second one is issued and both are sent to the user agent.

Here is the details on how I encounter the problem:
During authentication my Authenticator implementation requires access to the HTTP session before it invokes method register(request, response, principal, authType, username, password). When it accesses the HTTP session the Response is instructed to send Set-Cookie with a newly generated JSESSIONID and immediately after that - as part of the register method invocation - the Request is instructed to change the JSESSIONID. The problem is that Request.changeSessionId does not check whether the response is already instructed to issue a Set-Cookie header for the session ID and simply adds a second cookie to be sent to the browser. The HTTP response contains two Set-Cookie headers for JSESSIONID with different values, where the second is the newest one. As MS IE uses the first cookie it receives it is
not able to connect to the session with next requests.

Can you confirm this is not the intended behavior and let me know when this problem can be corrected?
Comment 1 Mark Thomas 2010-03-30 21:59:05 UTC
I can confirm that the current implementation does not expect other components to force the creation of a session earlier in the pipeline.

This looks to be fixable but I'm worried about the overhead that will be associated with the fix. My performance concerns may be unfounded but if you were able to find an alternative solution (eg not requiring the session to be created in your custom authenticator) then that might be a better overall solution.
Comment 2 Mark Thomas 2010-03-30 23:06:18 UTC
Created attachment 25219 [details]
Proposed patch to remove previously set session cookies

I haven't applied the attached patch to trunk. I'd appreciate some feedback onthe patch before I do.
Comment 3 Mark Thomas 2010-04-20 13:12:35 UTC
*** Bug 49158 has been marked as a duplicate of this bug. ***
Comment 4 Filip Hanik 2010-04-20 13:17:04 UTC

*** This bug has been marked as a duplicate of bug 49158 ***