I need to prevent Session Fixation, a particular type of session hijacking, in a Java web application running in JBoss. However, it appears that the standard idiom doesn't work in JBoss. Can this be worked around?
This defect (found here) points the way to the solution. The Tomcat instance that runs in JBoss is configured with emptySessionPath="true", rather than "false", which is the default. This can be modified in .../deploy/jboss-web.deployer/server.xml; both the HTTP and AJP connectors have this option.
The feature itself is used to eliminate the context path (eg. "foo" in http://example.com/foo) from being included in the JSESSIONID cookie. Setting it to false will break applications that rely on cross-application authentication, which includes stuff built using some portal frameworks. It didn't negatively affect the application in question, however.
This problem and the specific case in which it occurs is a problem in Tomcat as well as JBoss. Tomcat shares the emptySessionPath="true" effect (and actually JBoss inherits it from Tomcat).
This really seems like a bug in Tomcat and JBoss when you are trying to prevent session fixation attacks but the servlet spec (at least version 2.3) does not actually require the JSESSIONID to be defined or redefined according to any specific logic. Perhaps this has been cleaned up in later versions.
One workaround is to store the client address in the session. A response wrapper should validate the client address set in the session is same as the one accessing the session.
I came to know below code setting snippet from one of the forum. And I added below lines. But when I print the session ID after and before log in into the application it is same. How would I test session Fixation.
D:\jboss-5.1.0.GA\bin\run.cof file and add the below line.
set "JAVA_OPTS=%JAVA_OPTS% -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false"
in each context.xml of the jboss applications.
D:\jboss-5.1.0.GA\server\default\deploy\jbossweb.sar\context.xml
Related
We have a java web application which was hosted in tomcat 8. For session Management , we have been using the memcache which maintains non sticky based sessions. This has been working fine without any issues.
Now there is a requirement to upgrade the tomcat from 8 to tomcat 9 and the upgradation with the necessary jars for the tomcat 9 has been done. After the upgradation, we are facing an issue in the application where the session is becoming null. Some of the link in the app associated with the session are working fine and some of them when clicked gets me logged out of the session. Checking the logs, I see the session object null.
The memcached jars used as part of the tomcat 9 and copied under tomcat9/lib
memcache-session-manager-2.3.2
memcache-session-manager-tc9-2.3.2
jettison-1.1.jar
spymemcached-2.12.0
http-core-4.3
http-core-nio-4.3
we are using the 3rd party Serialization for this use case and they are also copied in the tomcat lib folder
kryo-3.0.3.jar
kryo-serializers-0.37.jar
minlog-1.3.0.jar
msm-kryo-serializer-1.9.3.jar
objenesis-2.1.jar
protobuf-java-2.6.1.jar
reflectasm-1.10.1.jar
With these jars , I am able to see the tomcat startup without any issues.
**<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
memcachedNodes="n1:ip:port"
lockingMode="auto"
sticky="false"
requestUriIgnorePattern= ".*\.(png|gif|jpg|css|js)$"
sessionBackupAsync= "false"
sessionBackupTimeout= "100"
copyCollectionsForSerialization="false"
transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"/>**
Followed the below link for setting up the memcache configuration in my application.
https://github.com/magro/memcached-session-manager/wiki/SetupAndConfiguration
Please help me if i am missing anything in the configuration.
Thanks
Pradeep
Have solved this issue by removing the param **requesturiignore pattern ** from the context.xml as this was creating different sessions.
Recently, we have upgraded our application server from JBoss EAP6.2 to EAP7.0.
Even though it runs non-HA profile aka standalone.xml, JBoss adds jboss.node.name at the end of JSESSIONID cookie.
For example,
Spring Boot generates a JSESSIONID as tHSf9v23SSDBMqJ1O7XFJZ9.... and when the request comes to browser, the cookie becomes tHSf9v23SSDBMqJ1O7XFJZ9.master:<jboss.node.name> which causes some compatibility issues.
I've run some experiments by manually calling response.addCookie. In that case, it does not add master suffix to the cookie. However, if Spring itself writes the cookie, it seems that JBoss picks it up and add master suffix. I know this case can be little confusing (it is to me), I'm happy to provide more information.
An old thread, but for those who still stumble upon it:
In EAP7/Wildfly11+ the session cookie will have a value in form :
<sessionId>.<instanceId>
Where instanceId is taken from Undertow subsystem config attribute instance-id. By default it is going to be set to value of jboss.node.name system property in standalone mode, and to <serverGroup>:<hostname> in domain mode.
You can customize the instanceId value via Undertow subsystem config:
Either via standalone.xml:
<subsystem xmlns="urn:jboss:domain:undertow:3.1" instance-id="${myValue}">
Or via corresponding cli:
/subsystem=undertow:write-attribute(name=instance-id, value=myvalue)
In which case you get a final JSession id that looks sth like this:
JSESSIONID=FdEyt_nZvyAV1gKpQ_3ZsSYeu41JycphvMdHcYeT.myvalue
The answer from #yntelectual is dead right and should be the accepted answer.
I just want to complement the fact that the observed behaviour is not a JBoss speciality.
It was introduced so Apache mod_jk and mod_proxy know which one of several possible application servers is working on a given session, and Apache Tomcat as the reference implementation for servlet containers shows exactly the same behaviour. Other containers such as JBoss, Glassfish, Geronimo do the same.
Check
jvmRoute on https://tomcat.apache.org/tomcat-9.0-doc/config/engine.html
jvmRoute on https://tomcat.apache.org/connectors-doc/reference/workers.html
route on https://httpd.apache.org/docs/2.4/mod/mod_proxy.html
jvmRoute on https://docs.oracle.com/cd/E18930_01/html/821-2416/gfaad.html
jvmRoute on https://geronimo.apache.org/GMOxDOC11/geronimo-tomcat-host-level-clustering-sample-application.html
I'm trying to have my JSESSIONID at ".mysite.com" so it can be shared across subdomains.
I have a 4.2.2 GA JBOSS instance doing this with this method: http://shchekoldin.com/2010/05/27/sharing-jsessionid-across-subdomains/ (which is from here: https://jira.jboss.org/browse/JBWEB-107) using the custom valve approach.
However on the EAP 5.1 version (I've compiled against JDK 1.6) the same custom valve doesn't kick in. I added some debugging but it never gets called.
Also, I tried turning on the SSO option in server.xml (as per https://community.jboss.org/wiki/JBossWebSingleSignOn) through the non-clustered method, but this plays no impact on it either.
Does anyone know how I can the JSESSIONID cookie to sit across subdomains on JBOSS 5?
(Side note, if I have "foo.bar.mysite.com" will this ".mysite.com" domain stored against the cookie work for multiple sub domains - this is for testing, in prod we just have the one level).
I also had same requirement. Share session across sites having sub-domain and parent domain within same .war file. e.g www.baseball.sports.com and www.hockey.sports.com.
To share JSESSION b/w these two sites need to add domain tag in jboss-web.xml.
File path : /app/jboss/jboss-eap-6.1/standalone/deployments/mason_production/.ear/.war/WEB-INF.
Add below entries :
.sports.com
I found what I needed:
You add <SessionCookie domain="example.com"/> under in the WEB-INF/context.xml of your application.
In J2EE web application, how do I disable the default HttpSession creation?
We have our own way of tracking session, we don't use default jsp/servlet session but the default session sets cookie in browser which I would like to avoid. Right now on every JSP page we specify as session="false" in page directive but often some developers missing this part, so I am trying to find a common place where I can control default session.
I am trying to find a common place where I can control default session.
The answer is servletcontainer specific since that's the one responsible for session creation and management. The standard Servlet API isn't responsible for that. It's unclear which servletcontainer you you're using, so here's a Tomcat targeted answer: create your own <Manager>.
Alternatively, you can also entirely disable cookie support and rely on URL rewriting only (but not do it). This way sessions won't survive among requests. You can do this in in for example Tomcat by setting the cookie attribute of the <Context> element to false.
If you're using another servletcontainer, then you need to consult its documentation based on the newly learnt information and keywords here above, or just to mention here which one it is.
How can I change the session timeout for the OC4J Enterprise Manager console?
It times out too quickly between deployments in our development environment.
The default session timeout of an application in OC4J is 20 minutes. If you need to change the same for an application, you have to explicitly set the session timeout value in web.xml.
This holds good even for Enterprise Manager as well, which is deployed as the application ascontrol. The web.xml file of ascontrol will be available at $ORACLE_HOME/j2ee/OC4J_INSTANCE/config/applications/ascontrol/ascontrol/WEB-INF/web.xml. You will have to introduce the session-timeout element in this file at the appropriate location (usually at the end), so that the XML is valid. A restart of the OC4J instance is required.
Do note that, this comes with no guarantees, and it is better to confirm via Oracle Support if this configuration change is supported.
Alternatively, you can use admin_client.jar or admin.jar to deploy your application.