https://issues.apache.org/bugzilla/show_bug.cgi?id=48913

           Summary: Request.changeSessionId adds a second Set-Cookie
                    JSESSIONID
           Product: Tomcat 6
           Version: 6.0.24
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: stephan.zlata...@yahoo.com


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?

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to