Security Issue with session tracking?!
teseling Feb 8, 2002 12:03 PMHello, I am using JBoss-2.4.4_Tomcat-4.0.1 and have spent some time on experimenting with security in Jboss/Tomcat. Everything works but I think I have found an issue which is unacceptable for using container managed security within my current project (and possibly other projects).
During the last couple of days I have run some tests and I am affraid that I have found what is in my eyes a security issue regarding the way tomcat/jboss tracks sessions in coordination with security.
Possibly this is a calculated risc in the J2EE specs or Jboss/Tomcat implementation, but to me it seems not acceptable for most e-commerce site. Also it could be a configuration error on my behalf, but in this case I want to make sure how to fix it and possibly help other avoiding the same problem.
Let me try to explain my findings and please give me your view on this.
Most sites have a public section of the website which anyone can visit. Once you want to purchase an item on a e-commerce website you will have to login for authentication and authorisation. Offcourse this goes together with switching to SSL, because username/passwords should never be send cleartext and any userdata should be protected, like creditcardnumbers. No problem you think, but underwater something happened during my tests which I think is not acceptable.
If I understand things correctly Jboss/Tomcat uses a cookie session tracking mechanism (JSESSIONID) to identify which HttpSession is related to this request. And the security state (identity & principals/roles) is assigned to the HttpSession. After a successful login (on the webcontainer) the identity and one or more roles are assigned to the HttpSession.
This means that (in memory) cookies are set on the client containing the JSESSIONID and is used on the serverside to relate any request to a certain HttpSession. When a user is not under SSL this cookie is send unprotected over the net. Now when someone sniffs your sessionID cookie on the Internet they can act as your session by either putting it in the requestheader or simple adding it to any url (like http://www.mysite.com/index.jsp;jessionid=12345).
Fair enough, because this session shouldn’t contain any personal/private information because if you would send this information it could also be sniffed. Therefore in the case of any sensitive info you will switch to SSL and possibly require a login.
Here the trouble starts. When you do switch between http to https, Jboss/Tomcat does not provide a new and secure cookie (which should hold a different jsessionid offcourse). This means that during the secure part of the session you keep the same jsessionid, which has been sent unprotected over the net.
So if anyone sniffed your insecure sessionid cookie, they can now take over you’re identity (including your security roles) by using this insecure jsessionid in any request. This means that they can access any business logic or private data for which you are authorised within this application!!!
Again I am not sure how this was intended in the specs, but to me this seems not secure enough when your site handles any private data. I haven’t looked at any of the sourcecode of Jboss/Tomcat and I could be doing something wrong, but it was suprisingly easy to setup this test.
There is a workaround, although it is not so elegant. When switching between non-ssl and ssl you can invalidate the non-secure session. Which Jboss/Tomcat does not seem to enforce in any way. This means that you will get a new and secure cookie (containing a different jsessionid). The biggest disadvantage would be that this would also mean that you will lose all state of the previous session, which could contain important information about the customer. The old session can no longer be abused because the session was invalidated and the HttpSession was cleared. Possibly the container could implement a mechanism that switches sessionid without loosing the session state??
I would like to here from you about your opinions.
Ps. my experience with Jboss is not that extensive and it could be that I am missing something, but I wanted to be absolutely sure.