Enterprise Integration Zone is brought to you in partnership with:

Nicolas Frankel is an IT consultant with 10 years experience in Java / JEE environments. He likes his job so much he writes technical articles on his blog and reviews technical books in his spare time. He also tries to find other geeks like him in universities, as a part-time lecturer. Nicolas is a DZone MVB and is not an employee of DZone and has posted 228 posts at DZone. You can read more from them at their website. View Full User Profile

Session Fixation and How to Fix It

08.04.2014
| 4630 views |
  • submit to reddit

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:

  1. Alice visits this online application and gets the value of the JSESSIONID cookie returned by the server
  2. Alice crafts a link to the application, including the previous JSESSIONID
  3. Alice sends the link to Bob
  4. Bob clicks on the link sent (rather stupidly, I’d say) or copies the link to his browser (the result is the same)
  5. 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
  6. 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.

1.<beans ...>
2.  <bean id="authFilter" class="org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter">
3.    <property name="sessionAuthenticationStrategy">
4.      <bean class="org.springframework.security.web.authentication.session.SessionFixationProtectionStrategy">
5.    </property>
6.  </bean>
7.</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:

01.@Configuration
02.@EnableWebSecurity
03.public class SecurityConfig extends WebSecurityConfigurerAdapter {
04.  
05.    @Autowired
06.    protected void configure(AuthenticationManagerBuilder amb) throws Exception {
07.        // Creates a simple principal in memory
08.        amb.inMemoryAuthentication().withUser("frankel").password("").roles("USER");
09.    }
10.  
11.    @Override
12.    protected void configure(HttpSecurity http) throws Exception {
13.        http
14.            .authorizeRequests()
15.             // Requires user to have USER role
16.            .antMatchers("/hello").hasRole("USER")
17.            .and().requiresChannel()
18.            // Requires channel to be HTTPS
19.            .antMatchers("/hello").requiresSecure()
20.            // Dont forget a simple form login!
21.            .and().formLogin();
22.    }
23.}

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.

Note: you’ll need a SSL-enabled servlet container.


Published at DZone with permission of Nicolas Frankel, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)