tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 55521] New: Race Condition in HttpSession#invalidate() / HttpServletRequest#getSession(boolean)
Date Wed, 04 Sep 2013 10:24:05 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=55521

            Bug ID: 55521
           Summary: Race Condition in HttpSession#invalidate() /
                    HttpServletRequest#getSession(boolean)
           Product: Tomcat 7
           Version: 7.0.40
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Servlet & JSP API
          Assignee: dev@tomcat.apache.org
          Reporter: christoph.ludwig@haufe-lexware.com

Created attachment 30798
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=30798&action=edit
code flow that exhibits the race condition

For session fixation protection, we have to discard a user's session and create
a new one whenever the user's login state changes. For this we rely on Spring
Security's SessionFixationProtectionStrategy that, at its core, uses the
following commands:

  session.invalidate();
  session = request.getSession(true);

Yesterday, we had a message in the log that indicates the latter command
returned the same session that was invalidated in the line before:
"Your servlet container did not change the session ID when a new session was
created. You will not be adequately protected against session-fixation attacks
(catalina-exec-339,
org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy,
SessionFixationProtectionStrategy.java:102)"

When I investigated this issue, I found there is in fact a race condition if
two threads (associated with requests from the same client) enter the session
fixation protection code in parallel. I attached a TXT file that illustrates
the code flow that leads to the race condition: When thread B calls
session.invalidate(), the call returns immediately becuase the session is
already in the "expiring" state. Since the session is not invalid yet, the call
to request.getSession(true) won't create a new session, though. So in effect,
thread B cannot obtain a new session.

The documentation at http://tomcat.apache.org/tomcat-7.0-doc/servletapi/ has no
indication that a session may not yet be invalid when session.invalidate()
returns. The session interface neither provides a way to detect "expiring"
session.

The error message appears only once in the production log files that go some
weeks back, so it seems to be an infrequent event. Nevertheless, it should be
possible to implement session fixation without a race condition.

Regards
Christoph

-- 
You are receiving this mail because:
You are the assignee for the bug.

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


Mime
View raw message