These last few weeks, I’ve been tasked to fix a number of security holes in our software. Since I’m not a security expert, I’ve been extremely interested in this, and have learned quite a few things. Among them is the Session Fixation attack.

The context is an online Java application. One part is avalailable through simple HTTP, where you can do simple browsing; when you enter credentials and successfully log in, you’re switched to HTTPS. This is a very common setup found online. For example, Amazon works this way: you browse the product catalog and put products in your basket in HTTP, but as soon as you login to checkout, you’re switched to HTTPS.

Now, the attack scenario is the following:

Alice visits this online application and gets the value of the JSESSIONID cookie returned by the server Alice crafts a link to the application, including the previous JSESSIONID Alice sends the link to Bob Bob clicks on the link sent (rather stupidly, I’d say) or copies the link to his browser (the result is the same) In the same session, Bob enters his credentials to enter the secured part of the application. He’s now authentified within the session referenced by the JSESSIONID sent by Alice Using the JSESSIONID sent in her own browser, Alice is able to operate the application with the same credentials as Bob

Wow! If the site is an online banking site, this is extremely serious, giving potential attackers access to your bank account. This issue is known as Session Fixation and is referenced by OWASP.

Though we can require users not to click on links sent by emails, that’s a request for "aware" users, not everyone’s grandmother. We definitely need a more robust solution. The proposed remediation is quite easy to design: when the user switches from HTTP to HTTPS, he’s sent another JSESSIONID. Basically, his old session is destroyed, and a new one is created with all attributes of his former session.

It is possible to implement this behavior. However, if one is using Spring Security, it’s available out of the box through the SessionFixationProtectionStrategy class. Just plug it into the UserNamePasswordAuthenticationFilter .

<beans...> <bean id= "authFilter" class= "org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter" > <property name= "sessionAuthenticationStrategy" > <bean class= "org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy" > </property> </bean> </beans>

Beware, most examples available on the Web only show usage of the strategy for session management!

Better yet, using JavaConfig and the WebSecurityConfigurerAdapter , it is configured out-of-the-box. Here’s an example of such configuration, with the strategy already configured:

@Configuration @EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { @Autowired protected void configure ( AuthenticationManagerBuilder amb ) throws Exception { // Creates a simple principal in memory amb . inMemoryAuthentication (). withUser ( "frankel" ). password ( "" ). roles ( "USER" ); } @Override protected void configure ( HttpSecurity http ) throws Exception { http . authorizeRequests () // Requires user to have USER role . antMatchers ( "/hello" ). hasRole ( "USER" ) . and (). requiresChannel () // Requires channel to be HTTPS . antMatchers ( "/hello" ). requiresSecure () // Dont forget a simple form login! . and (). formLogin (); } }

Get the sample project - it is also a good template project for Spring MVC & Spring Security with JavaConfig, and check the JSESSIONID cookie value changed.