Bug 40222 - Default Tomcat configuration alows easy session hijacking
Summary: Default Tomcat configuration alows easy session hijacking
Status: RESOLVED DUPLICATE of bug 45255
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.0.15
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2006-08-09 13:39 UTC by Tomas Hulek
Modified: 2010-08-25 15:01 UTC (History)
1 user (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Hulek 2006-08-09 13:39:52 UTC
Tomcat should not carry over a session id generated under HTTP do HTTPS
requests. After authentication, the session ID becomes THE secret password.

In reality, many standard servlets (including e.g. Apache MyFaces servlet)
return a session ID on the first request. After switch to SSL (with
authentication), the session ID is retained, thus allowing easy session hijacking.

In the ideal world the session should survive the switch from HTTP to HTTPS, but
the session ID must change upon switch to HTTPS.
Comment 1 Yoav Shapira 2006-12-26 06:45:59 UTC
Are you sure the same session is indeed carried over?  I thought we'd
implemented the opposite (new session when moving from HTTP to HTTPS), quite
purposefully for security, as far back as Tomcat 3.x.  See for example
Comment 2 Tomas Hulek 2006-12-26 11:31:47 UTC
(In reply to comment #1)
> Are you sure the same session is indeed carried over?  I thought we'd
> implemented the opposite (new session when moving from HTTP to HTTPS), quite
> purposefully for security, as far back as Tomcat 3.x.  See for example

Yes, I am sure. The problem can be demonstrated like this:

1) Using HTTP, go to an insecure page which assigns a JSESSIONID (eg. any JSF page)

2) Notice the JSESSIONID (which can be sniffed on the network by man-in-the-middle)

3) Go to an authenticated HTTPS page (eg. via form-based login). Look at the
"secure data".

The JSESSIONID is still the same!

4) From another computer, write the URL of the authenticated page including the
JSESSIOND obtained in step 2 above. Bingo - the hacker is in!

In order to circumvent the problem, we had to insert code into the login page
which invalidates previously assigned session, loosing all session info.

An easy fix in Tomcat would be to change (or append) the JSESSIONID upon
switching from HTTP to HTTPS. Switching from HTTPS to HTTP is already forbidden
as you mention, which is correct.

Comment 3 Chris Halstead 2007-01-11 10:46:35 UTC
I was able to easily replicate this on 5.5.20.

RE #1 - unless I'm misreading the referenced post, that discussion is about new
sessions being created when going https-->http, not the other way around.  
Comment 4 Tomas Hulek 2007-01-12 00:37:49 UTC
NO, the problem is that the SessionID, when switching from HTTP to HTTPS remains
the same!!!

I believe this is a serious security issue and should be dealt with.

The attack scenario again:

1) A HTTP page assigns a SessionID

2) Man-in-the-Middle notices the SessionID

3) Upon switch to HTTPS, the SesssionID remains the same. After login to HTTPS
secure area the man-in-the-middle is able access all HTTPS pages just using the
SessionID obtained.
Comment 5 Remy Maucherat 2007-01-12 04:33:44 UTC
The session id as defined by the specification can be used by the user for a
variety of things, or can be pretty much set in stone due to other factors
(session clustering, persistent storage). So I'd suggest calming down and
relaxing, because this is not going to be fixed.

The proprietary solution (which could be enabled using a valve) is to expire the
session and create a new one with a different session id, and as a convenience,
Tomcat could copy over some of the session data. Feel free to submit such a
valve if you'd like to.
Comment 6 Mark Thomas 2007-01-20 18:09:52 UTC
Marking this as an enhancement and awaiting a patch for review.
Comment 7 Mark Thomas 2010-08-25 15:01:58 UTC
Tomcat now provides an option to change the session ID on authentication. This should address the concerns raised here.

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