Session Fixation and How to Fix It
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
JSESSIONIDcookie 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
JSESSIONIDsent by Alice - Using the
JSESSIONIDsent 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 Fränkel. See the original article here.
Opinions expressed by DZone contributors are their own.