JSessionID is overwritten when switching between H

2020-07-26 11:35发布

问题:

We have the following situation going on:

  1. Go to http://website/ and click on a link to http://website/appX
    Check that the cookie shows JSessionID with secure = NO.

  2. Open another browser window or tab and go to https://website/ and click on a link to https://website/appY.
    Check that the cookie shows JSessionID with secure = YES.

  3. Try to interact with the window/tab created in step 1. I'm getting a session expired...

If we repeat the steps but use https://website/appX instead of https://website/appY in step2, then the JSessionID cookie remains with Secure=NO.

All cookies have JSessionId with jvmRoute appended in the end.

--

We are using:

Apache (2.2.3-43.el5_5.3) + mod_jk (w/ sticky sessions) and load balancer configured to several JBoss instances (v 4.3.0).

I have found only a link with the exact same issue (normally the other ones are using PHP): http://threebit.net/mail-archive/tomcat-users/msg17687.html

Q: How can we prevent the JSessionId cookie from being rewritten ?

回答1:

From a security point of view, it is the correct behavior, because a attacker could steal the session id/cooki used in https if the same session id/cooki is used in http too.

For more details see my answer here.

So if you want to build a secure application (I excpect this, because you use https), then you must not change this!



回答2:

SessionID/Cookie will not be preserved when making switch from HTTPS to HTTP or vice versa. You can pass these parameters in URL to pass the values.



回答3:

In the connector configuration (for Tomcat's bundled version in JBoss) in deploy/jboss-web.deployer/server.xml, there's an emptySessionPath attribute that controls whether the session cookie is set on the context path or not.

<Connector port="8080" address="${jboss.bind.address}"    
     maxThreads="250" maxHttpHeaderSize="8192"
     emptySessionPath="true" protocol="HTTP/1.1"
     enableLookups="false" redirectPort="8443" acceptCount="100"
     connectionTimeout="20000" disableUploadTimeout="true" /> 

If you set this to false, you'll have one cookie per application, which prevents the problem from happening.