You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2013/09/04 12:24:05 UTC
[Bug 55521] New: Race Condition in HttpSession#invalidate() /
HttpServletRequest#getSession(boolean)
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
[Bug 55521] Race Condition in HttpSession#invalidate() /
HttpServletRequest#getSession(boolean)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55521
--- Comment #2 from Christoph <ch...@haufe-lexware.com> ---
Mark, it would be great if you'd ask one of your colleagues to take a look at
the additional issues in Spring Security you observed.
As far as Tomcat is concerned, the race condition I observed would no longer
exist if the early check of the expiring field before the synchronized block is
entered would be removed. Of course, I don't now whether this check is merely
the result of an over-eager optimization or whether it is needed in some
situation I am not aware of.
--
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
[Bug 55521] Race Condition in HttpSession#invalidate() /
HttpServletRequest#getSession(boolean)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55521
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
I've taken a look at this and there are some things we can do in Tomcat to
ensure that a call to invalidate() doesn't return until the session has been
invalidated.
However, there may still be an issue that needs fixing in Spring Security.
Looking at SessionFixationProtectionStrategy.applySessionFixation() it is
possible (although even less likely than the issue you have seen) for
concurrent requests to generate a series of invalidate / create / invalidate /
create etc. events. It is pretty unlikely but is possible. Since I work for
Pivotal, I'll ping one of the developers.
--
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
[Bug 55521] Race Condition in HttpSession#invalidate() /
HttpServletRequest#getSession(boolean)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55521
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
Thsi has been fixed in trunk and 7.0.x and will be included in 8.0.0-RC2 and
7.0.43 onwards.
--
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
[Bug 55521] Race Condition in HttpSession#invalidate() /
HttpServletRequest#getSession(boolean)
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55521
--- Comment #4 from Christoph <ch...@haufe-lexware.com> ---
Thanks for the very prompt fix!
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