|Summary:||how to access ssl session ID out of tomcat to prevent session hijacking and allow for phishing protection|
|Product:||Tomcat 6||Reporter:||Ralf Hauser <hauser>|
|Component:||Jasper||Assignee:||Tomcat Developers Mailing List <dev>|
Description Ralf Hauser 2003-08-24 06:50:46 UTC
hi, I am using the tomcat SSL engine. In order to avoid session fixation attacks (see more on that in http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22649), I would like to put the SSL session ID into my jsessionid. RFE: enhance the "SSL ho wto" description at the above URL with a section on how to do this. P.S.: I am aware that this possibly reduces the availability of my application as per http://groups.yahoo.com/group/jetty-support/message/2085
Comment 1 Ralf Hauser 2004-03-05 07:31:50 UTC
one example where hijacking is particularly likely when you integrate with third-party applications that after doing their job should send the user back to your own application and you don't want the user to be forced to log into your own application again! While it should be possible to offer such a process to the user of my application, I would like to maintain some level of mutual distrust with that third-party provider. One example of such third-party provider might be paypal with their IPN - see related post in http://www.paypaldev.org/topic.asp?TOPIC_ID=5255
Comment 2 Mark Thomas 2004-06-19 11:46:12 UTC
This enhancement request has been transferred to Tomcat 5 because: - TC4 and TC5 share the connectors - TC4 is no longer being developed, only supported
Comment 3 Yoav Shapira 2004-07-21 18:29:07 UTC
Please suggest text in patch diff format for "RFE: enhance the "SSL ho wto" description at the above URL with a section on how to do this." and we'll consider adding it.
Comment 4 Yoav Shapira 2004-10-29 18:43:23 UTC
I guess you don't care enough to suggest such text, so I'm closing the item.
Comment 5 Ralf Hauser 2004-10-30 08:01:14 UTC
I do care, but I don't know the technical solution how to do it. If you tell me how to access the SSL session ID out of my web application, I am happy to provide the text patch you have asked for.
Comment 6 william.barker 2004-10-30 21:12:44 UTC
Try String sslID = (String)request.getAttribute ("javax.servlet.request.ssl_session");
Comment 7 Ralf Hauser 2004-10-31 08:27:41 UTC
Thanks for the hint, but unfortunately, after tomcat 3.2. SSLSupport.SESSION_ID_KEY appears to be no longer present in coyote. For those web-applications that do not use session cookies because quite some users do not want cookies - how are they supposed to protect against session hijacking? Still, if for example the web application lets paypal's IPN know how to return into an ongoing (url-rewritten) session, one has to trust them not to spoof the remoteAddress?
Comment 8 william.barker 2004-10-31 21:55:22 UTC
It seems that Tomcat 3.3.x & 4.1.x work fine. With Tomcat 5 you need to access a standard attribute to trigger, and then it works fine: request.getAttribute("javax.servlet.request.key_size"); String sslID = (String)request.getAttribute ("javax.servlet.request.ssl_session"); It's true that TC 3.3 has a setting to deny access to the servlet session if the SSL session doesn't match. In TC >= 4, it is easy enough to do this type of check in a Filter.
Comment 9 Ralf Hauser 2004-11-01 07:07:40 UTC
thx, seems to work! Had troubles finding the doc pages in CVS to provide the promised diff patch
Comment 10 Yoav Shapira 2004-11-18 16:01:24 UTC
Docs enhanced accordingly for Tomcat 5.0.30 and 5.5.5.
Comment 11 Ralf Hauser 2004-11-19 07:11:00 UTC
thx a lot (also in the name of future security-concerned application programmers) for honoring this documentation RFE after 15 months (and unfortunately having to go through the apparently unavoidable WONTFIX/INVALID episodes :( ). Furthermore, I contend that these functions also will become key to true phishing protection as per https://bugzilla.mozilla.org/show_bug.cgi?id=268835!
Comment 12 Ralf Hauser 2005-01-20 01:23:25 UTC
good practice for such a anti-session-hijacking/anti-cross-site scripting is to implement a 2 out of 3 approach: i.e. SSL-session ID, remote IP and user-agent are compared between each http request and only if 2 out of 3 remain the same, the login-status is maintained. Not 3 out of 3 because quite some DSL-dynamic IP assignments change relatively frequently and users are annoyed if the have to re-authenticate often during a session. Similarly, some browsers do not keep an SSL session alive for the same duration as a application-user session may last.
Comment 13 Remy Maucherat 2007-04-24 15:49:52 UTC
It is not possible to change the session id of a session, it has to be asssumed. If you want to submit a valve which would enforce "better" security (= a lame hack which would pretend to be secure), then I would be ok to commit it and let this bug report live. Despite the dynamic IP thing, I think 3 out of 3 is a minimum requirement, despite possible problems (IPs do not change every 5s, so I don't see the point, and if they do, let the user log back in). Otherwise -> INVALID.
Comment 14 Lucas Galfaso 2007-10-25 18:43:08 UTC
A browser is free to open multiple SSL connections to a single Tomcat, even when doing this might be a performance hit. With this in mind, any way to tie the JSESSIONID to the SSL id is not the proper way to prevent session hijacking.
Comment 15 Ralf Hauser 2007-10-25 20:06:56 UTC
Lucas, you are right that there can be multiple legitimate SSL Session IDs with one JSESSIONID. So while I stick to the statement that observing the SSL Session ID is still one good measure against Session Hijacking, if applied alone, it may also lock out legitimate additional SSL sessions. At least for sequentially changing SSL-IDs, we account for with the described "n-1 our of n" approach (comment 12). So if the other n-1 parameters to considered stay the same, the mechanism probably even works with simultanous sessions with IDs A, B, C since the tomcat application for each request will just assume that it is a change from A->B, then from B->C, C->A and so on - not noticing there are actually multiple simultaneous SSL sessions going on in parallel. Anyway, we have the approach in operation since months with hundreds of users and no problems.
Comment 16 Lucas Galfaso 2007-10-26 07:39:46 UTC
(In reply to comment #15) Ralf, I understand that Tomcat should provide ways to prevent session hijacking, but building something into Tomcat to associate a jsessionid with the ssl id is not the solution. This may be an interesting issue for the Tomcat dev list, but this is not a bug. You can have the same behavior that you are asking to be build in into Tomcat using a filter that is specific to your application, and I am somehow inclined into not building into Tomcat something that prevents browsers work within the specs.
Comment 17 william.barker 2007-12-28 21:01:40 UTC
In TC 3.3 this is a setting, and in TC >= 4.x, it is easy enough to implement this as a Filter. I don't see that it is useful to implement this "feature" in the core Tomcat code, especially since it may break perfectly valid SSL connections.