Our security team ran a scan that tells us that we're vulnerable to session fixation and the docs tells us that in tomcat we should use the changeSessionIdOnAuthentication setting in context.xml.
What would be the equivalent move in WebSphere 8.5?
I had the same issue with WAS 8.5. Ended up using spring security to configure the session fixation issue.
<security:session-management invalid-session-url="/login" session-authentication-error-url="/login" session-fixation-protection="newSession">
<security:concurrency-control error-if-maximum-exceeded="true" max-sessions="1" expired-url="/login"/>
WebSphere 8.5 is using a servlet api version that is < 3.1, therefore you can't use changeSessionId() method of HttpServlet Request.
What you can do instead is, at the point where you are authenticating your user in your application, probably, attemptAuthentication() or similar methods, you can do:
HttpSession session = request.getSession(false);
if(session != null)
session.invalidate();
session = request.getSession();
The above provides protection against session fixation attack.
Related
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.
I am new with spring ,I have a doubt about spring session management and spring security session ,whether both concept are same or different ? If different what are that ? Any suggestion ?
May you be a little bit more specific in your question?
In Spring:
session can refer to one of the scopes that a bean belongs to. For example, if you define an instance (bean) of a class a org.something.Counter with scope session, whenever you will access that bean during a web session you will have the same instance of the object. Web session does not require Spring Security in order to exists. You can start from here to understand a little bit more about the session scope in Spring.
session may refer to HttpSession as speciffied by the Servlet API. This is not really related to Spring, even if you can use the standard HttpSession from within Spring, is more in general related to the Servlet API.
In Spring Security:
If you are talking of Spring Security, instead of session I would talk of SecurityContext. The SecurityContext is actually stored as an HttpSession and restored to the SecurityContextHolder at every request. Here is were all security-related infos are stored for the current session. See here for more details. In general a SecurityContext (at least at a very basic level) exists from the moment you login to the moment you logout. Because it is stored as an HttpSession it expires when the HttpSession expires (again, see the Servlet API specifications for more details)
Luca
I've created my own UserDetailsService and UserDetails implementations and hooked it up. I can create users, and login as users. However, if I login, logout, and then login again, I'm getting a redirect to a timeout error page. This is because I'm preventing concurrent logins, but it's not working - it used to with the "hello world" auth examples, but now with my own implementations that piece has stopped working correctly for some reason. Spring basically thinks there are 2 sessions when I login, logout, and login again.
Now - I thought this was all handled automatically ....perhaps using your own UserDetailsService means you actually have to implement session management somewhere else as well? I'm sort of blown away that's not mentioned in the docs or in the book Spring Security 3.1 so I'm assuming I'm missing something.
This is in my web.xml bit for listening to session life cycle events
<!-- This listener updates spring-security on httpsession lifecycle events,
in this case to ensure each user can have only 1 session at a time. -->
<listener>
<listener-class>org.springframework.security.web.session.HttpSessionEventPublisher</listener-class>
</listener>
and this is in my security.xml to prevent concurrent logins
<!-- This prevents the user from logging in more than once simultaneously -->
<security:session-management
invalid-session-url="/timeout.htm">
<security:concurrency-control
max-sessions="1" error-if-maximum-exceeded="true" />
</security:session-management>
My logout in the security context file is
<security:logout logout-url="/logout"
invalidate-session="true" delete-cookies="JSESSIONID,SPRING_SECURITY_REMEMBER_ME_COOKIE"
logout-success-url="/login.htm?logout" />
I've tried a few permutations of that. None seem to work. invalidate-session="true" is the default value, so I shouldn't even have to specify this. But it doesn't seem to be happening.
O.k., I just reverted everything to try and do in-memory auth and I'm getting the same errors. Meaning, I'm not using my custom implementations anymore. Sorry - I clearly have something wrong somewhere...and this is proving extremely difficult to find. I might have to start from scratch.
Do I have to do something special on logout with my custom UserDetailsService?
Any feedback or guidance is much appreciated.
To my understanding the error-if-maximum-exceeded attribute should be false. Settings the value to false will cause the original session to expire instead of throwing a exception as explained in http://docs.spring.io/spring-security/site/docs/3.0.x/reference/appendix-namespace.html#d0e7768
I discovered it was a conflict between using <session-management> in my configuration and my servlet container. I'm using STS 3.5 (custom Eclipse for Spring projects) with vFabric server that runs in the IDE. The Reference documentation did not refer to this in the actual Session Management section (Section 8). However, buried in Section 4 on auth is this little gem:
Note that if you use this mechanism to detect session timeouts, it may falsely report an error if the user logs out and then logs back in without closing the browser. This is because the session cookie is not cleared when you invalidate the session and will be resubmitted even if the user has logged out. You may be able to explicitly delete the JSESSIONID cookie on logging out, for example by using the following syntax in the logout handler:
<http>
<logout delete-cookies="JSESSIONID" />
</http>
Unfortunately this can’t be guaranteed to work with every servlet container, so you will need to test it in your environment
Well, apparently it doesn't work in STS 3.5
At first I tried to eliminate sections of my <session-management> tag so I could just control concurrency (i.e. have the user only able to log in with one session at a time). However, I just kept getting errors.
So, at this point I've removed the session management stuff altogether and will come back to it when ready to deploy.
I am using Spring MVC 3.1 and developing a web application.
I am storing loged in user name and password in session.since session is stored in cookie, once cookie is disabled I am not able to log in.
is there is any solution in SPRING MVC to store session other then cookie.
Thanks
You want to use URL rewriting to persist the JSESSIONID in the URL's across requests. You can configure the ServletContext to use the URL tracking mode (instead of COOKIE) as described here.
With Servlet 3.0 you do this:
<session-config>
<cookie-config>
<tracking-mode>URL</tracking-mode>
</cookie-config>
</session-config>
I noticed that in my application (Java EE 6, Spring MVC 3.2.4, Spring Security 3.1.4) JSTL's <c:url> tags start adding the sessionid value to each URL when cookies get disabled. Spring Security works normally. I did not have to do any configuration to achieve this.
I'm new to Spring Security, I used it only for the authorization. I know, that Spring Security provides authentication and authorization solutions. Of course, in some cases registration is nothing more than checking a validity of email, confirmed password and so on, putting user's data in the database. Is there any Spring Security's code that should be used for the registration? I didn't find any registration tutorials (but there are a lot of login tutorials). Thanks in advance.
By now there is no standardized registration process. You need to write a Service implementing UserDetailsService an pass it to your authentication-manager (here a DAO is used):
<authentication-manager alias="authenticationManager">
<authentication-provider user-service-ref="userDao" />
</authentication-manager>
Check the Spring Security Docs: http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/