Changing JSESSION ID with Tomcat 7 - tomcat7

According to the tomcat docs, tomcat7 is not vulnerable to session fixation attack. But my tomcat 7.0.25 as well as 7.0.27 is vulnerable to this attack. JSESSIONID cookie value is not getting changed on successful login.
I added following Valves to my conf/context.xml. But this didn't work. Please help me.
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator" changeSessionIdOnAuthentication="true" />
<Valve className="org.apache.catalina.authenticator.SSLAuthenticator" changeSessionIdOnAuthentication="true" />
<Valve className="org.apache.catalina.authenticator.SpnegoAuthenticator" changeSessionIdOnAuthentication="true" />
<Valve className="org.apache.catalina.authenticator.DigestAuthenticator" changeSessionIdOnAuthentication="true" />
<Valve className="org.apache.catalina.authenticator.FormAuthenticator" changeSessionIdOnAuthentication="true" />
I have also come to know that JSESSION ID cookie value only changes on authentication. What does authentication means ? Is it switching the application from http to https ?
Is there anything already built which can change the the jsession id value on login ? Right now I am changing this via code.
Thanks in advance. Please let me know if you need more info.
Regards,
Prashant Gupta

Are you sure your application uses server security.
These configuration only affect this behaviour if you're using it.
If your authentication uses for example custom or spring security authentication they will not apply and you will have to do this yourself.
For example in spring sec there are parameters for that.
Regards

Related

Apache Ignite seems to cause session fixation

I'm using Apache Ignite to cluster web sessions, and use Spring security to do the form-based authentication. The software I use are:
JDK 1.8.0_60
Apache Tomcat 7.0.68
Apache Ignite 1.5.0.final
Spring Security 3.1.3.RELEASE
(Without Apache Ignite, the form based authentication works fine, and the JSESSIONID cookie gets changed upon the success of authentication to protect against session fixation attacks, as expected.)
With Apache Ignite, I cannot log in, and I get the following warning:
2016-04-18 16:49:07,283 WARN org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy/onAuthentication 102 - Your servlet container did not change the session ID when a new session was created. You will not be adequately protected against session-fixation attacks
If I turn off session fixation protection in the Spring configuration as below:
<http>
...
<session-management session-fixation-protection="none" />
...
</http>
It works. (However as a result, the JSESSIONID cookie does not change upon the success of authentication.)
As advised by Valentin (, thanks), I tried the nightly build from Apache Ignite, of version 1.6.0-SNAPSHOT#20160419-sha1:186c8604. Indeed, it works.
It works with the following Spring security configuration:
<http>
...
<session-management session-fixation-protection="none" />
...
</http>
And of course the JSESSIONID cookie does not change upon the success of Spring security authentication.
Then I comment out the following configuration:
<session-management session-fixation-protection="none" />
It also works. And upon the success of authentication, the JSESSIONID cookie gets changed as it is supposed to do.
OK, I'll use Ignite version 1.5.0.final for now (with no session-fixation-protection), and wait for the release of version 1.6.x.
Tomcat 7 has in-built functionality for session fixation,
Changing the jsessionid on authentication to prevent session fixation attacks altogether
Tomcat is not letting the application to change the session ID.

Trouble with session attributes getting replicated in Tomcat 6

I have configured Tomcat 6 with in-memory session replication. I am also using IIS 7 (I know, I know) and the AJP connector via isapi_redirector. The cluster is working properly and I am able to replicate session attributes using the SessionExample in the examples war. The problem is that I am unable to do the same in my custom application. I have added the distributable tag to the web.xml file on both servers in my test cluster. However, I don't see any message in the logs mentioning the attributes getting sent to the cluster (I see them for SessionExample). The only primary differences that I can see in my app from the examples:
The examples war uses servlet 2.5. I am still required to use 2.4.
My application uses SSO and requires the user to login.
The application is a portal application.
Also, in the code of the application, I am setting a simple string in the attribute, so nothing fancy.
So, I was wondering if anyone has some tips to get this working?
Thanks
Here is the cluster section within of my server.xml:
<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"
channelSendOptions="6">
<Manager className="org.apache.catalina.ha.session.DeltaManager"
expireSessionsOnShutdown="false"
notifyListenersOnReplication="true"/>
<Channel className="org.apache.catalina.tribes.group.GroupChannel">
<Membership className="org.apache.catalina.tribes.membership.McastService"
address="228.0.0.104"
port="45564"
frequency="500"
dropTime="10000"/>
<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
address="auto"
port="4000"
autoBind="100"
selectorTimeout="7000"
maxThreads="6"
timeout="15000"/>
<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"
timeout="70000"/>
</Sender>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
</Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve"
filter=".*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;"/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>
<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
tempDir="/apache-tomcat-6.0.37/war-deploy/war-temp/"
deployDir="/apache-tomcat-6.0.37/webapps/"
watchDir="/apache-tomcat-6.0.37/war-deploy/war-listen/"
watchEnabled="true"/>
<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>
Sorry. I found the issue. I was expecting to see messages in the log regarding the creation of the session attributes. I didn't realize that the examples project had a session listener that was outputting the messages to the log. I was thinking that it was simply from the log level that I had set.
Thanks to anyone who read this post.

Acegi pligin not enabling HTTPS with 'forceHttps' param

I am working on an old application which has huge code from legacy.
Application is based on Spring 2.0 and using Acegi plugin for security. The Tomcat server is successfully configured on HTTPS port.
Now I need to redirect the login over HTTPS. I tries setting following in my template_spring_config.xml
<bean id="authenticationEntryPoint" class="src.auth.acegi.myAuthenticationProcessingFilterEntryPoint">
<property name="loginFormUrl" value="http://#domain.name#/welcome"/>
<property name="forceHttps" value="true"/>
</bean>
Help found so far indicates that this much should be enough to redirect on HTTPS. But this is not working at all and my Request for login remains on HTTP.
I cannot switch to Spring-Security and higher Spring versions due to time constraint.
Please help if you know what else I need to do.
It's difficult to say for sure since you are using a custom entry point implementation (which may behave differently), but you are using an absolute URL, which will probably override the default logic for building the redirect. Try using https:// rather than http:// for your login URL scheme.
Note that you really shouldn't be using Acegi since development stopped on it a long time ago. It contains most (possibly all) of the vulnerabilities that have subsequently been patched in Spring Security. The same goes for Spring itself.

is it mandatory to configure both in my application?

I am using spring security for authentication. i have applicationContext-security.xml and custom login page(login.jsp). i have to implement remember me functionality. i have configured below two things. is it mandatory to configure both or one is enough? Please help me.
login.jsp:
<input type="checkbox" name="_spring_security_remember_me" />Remember Me
security.xml:
<remember-me key="_spring_security_remember_me"/>
are both above lines mandatory? also is _spring_security_remember_me convention is mandatory? Thanks!
The checkbox in the JSP is used to let the user choose if a remember-me cookie should be set or not, allowing for transparent authentication later. Spring excepts such a request parameter to decide if the cookie must be set or not.
The key in the security.xml is used to generate a more difficult to guess hash to store in the cookie. You should put something only known by you. It's a secret key. See http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#remember-me

Configuring Spring Security Ldap 3.0 to work with Active Directory LDS

I am hoping that someone will help me out with a really frustrating problem I have.
Currently I am trying to get Spring Security 3.0 Web App to authenticate with an AD LDS instance but I keep getting this error 'Bad Credentials'. Unfortunately I dont have anything more to go on at the moment.
Below is a copy of the Security configuration being used:
<authentication-manager alias="ldapAuthenicationManager">
<ldap-authentication-provider user-dn-pattern="CN={0},OU=Users,O=JLP,C=UK" >
</ldap-authentication-provider> </authentication-manager>
<ldap-server url="ldap://servner ip/o=JLP,c=UK" manager-dn="CN=Manager,O=JLP,C=UK" manager-password="manager" />
I suspect the problem is caused by the <Ldap server> tag and that the manager-dn is not configured correctly. The DN of the Manager is copied directly from AD LDS - have I not provided enough information? Or does the password need to encrypted\hashed?
Has anyone done anything like this with LDS - how did you work around this problem?
Applogies that this is so vague, but this is as much information as I have to go on. Does any one have any suggestions of things to look at or for solutions?
All help is gratefully recieved!
Cheers
Mo
I am not sure if things would be significantly different for LDS but can you try upgrading to spring security 3.1 as it has a specialized Authenticator for AD.
It does not need manager account as it tries to bind using the username/password being authenticated. Also the configuration is minimal (No DN, search pattern, etc to be provided)
<security:authentication-manager>
<security:authentication-provider ref="activeDirectoryAuthenticationProvider"/>
</security:authentication-manager>
<bean id="activeDirectoryAuthenticationProvider"
class="org.springframework.security.ldap.authentication.ad.ActiveDirectoryLdapAuthenticationProvider">
<constructor-arg value="${activedirectory.domain}" />
<constructor-arg value="${activedirectory.server}" />
<property name="convertSubErrorCodesToExceptions" value="true"/>
</bean>
where domain = example.com (from your example, jlp.uk) and server = ldap://ip
I remember that I came across with the same issue and the solution was to set the value of manager-dn
to manageruser#yourdomain
e.g.
<ldap-server url="ldap://servner ip/o=JLP,c=UK" manager-dn="morrislgn#example.com" manager-password="manager" />
Thanks for your answers they were very helpful.
Also found that the user account you are using for the manager-dn needs to be added to the reader role within LDS to allow it to search.
If you add the user role to the Administrators group you can connect but not search.
Cheers for your help
Slight necromancy here, but for those who stumble across this via Google, the most helpful tool I found regarding configuring my LDAP connection was to install Apache Directory Studio LDAP browser. It was via this tool that I was able to get verbose enough error messages to discover what was wrong with my LDAP configuration, and how to correct it.

Resources