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.lud...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
