Spring Security Session Fixation

In this article of our spring security course, we will look at the Spring Security session fixation and how to prevent the session hijack in our spring application.

The session fixation is a very common and most frequent type of attack where it is possible for a malicious attacker to create a session by accessing a site, then persuade another user to log in with the same session (by sending them a link containing the session identifier as a parameter, for example). Think of session fixation as kind of vulnerability where attacker will trick you to login to application and then use your session to get access to the same site. Keep in mind the following important point for better understanding.

This differs from session hijacking. In session hijacking, the attacker will steal your authenticated session to get access to the application.
In session fixation, the attacker will first get a valid session from the application and then redirect the user to the login page to let you login so they can use the session to login to application.

1. Understanding Session Fixation Attacks

Before we get into details of spring security session fixation and how the security can help us fix this potential issue, it’s important that we clearly understand the problem. Session fixation is an attack and can be done in multiple ways. Here is how a high level attacks look like:

Attackers get a valid session id from our application.
They trick victim to authenticate, where attackers will pass the same session id in the authentication request.
Victim is authenticated with the same session id (we will talk about the same session ID later).
Attackers can now use the same session id to access the secure area of the application, as this session is already authenticated by the application.

This is not a problem if the user is not logged in, but it will become serious if the application will continue to use the same session id after user is authenticated. Keep in mind Spring security authentication rely on the session id to check if the session is authenticated or not. With the same session id, malicious attacker can use the same session id to get authenticated passing no username or password. There are multiple variation of this attack, let’s check few of them:

1.1 Random SID

There are many applications which can accept not only the session id but any other ID provided by the client. If this is the case, it’s easy for the attacker to simply generate a random ID and pass it with the login request.

1.2 Server Session ID

If the application only allows the session id generated by the application, it will add a step for the attacker to get a valid session id from the application before they can trick the victim to do a login using their session id. There are few additional challenges for the attackers in this approach.

Application sessions id are time bound. They need to ensure that no invalid session id is being used, also the session can be timed out before they can use it.

Once the session is obtained, they can redirect the customer to login page with their session id: https://www.javadevjournal.com/login?SID=987654321. This is just an example, but remember in a typical Java based web application, you can pass the session id using the following options:

URL
Cookies
SSL

Here is a high level workflow to give you more clear understanding as to how the session fixation attack’s work

2. Protection Using Spring Security Session Fixation

By default, Spring security protects the session fixation attack by creating a new session or otherwise changing the session ID when a user logs in. spring security session fixation ensures the attacker cannot use the old session to gain access to the application. You can control the spring security session fixation policy using the sessionManagement configuration:

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
    ...
    sessionManagement()
    .sessionFixation().none();
}

Spring security provides different options for the session management and session fixation, you can always change or adapt it as per your need.

Session Fixation Policy	Description
`none()`	Spring security will disable the session fixation protection.
`migrateSession()`	When the user successfully authenticated, a new session will be created and it will move old session values to the new session. (Default and applicable for most of the cases)
`newSession()`	When the user successfully authenticated, a new session will be created, and it copies no attributes from the old session.
`changeSessionId()`	This is done using the new Servlet containers (Servlet 3.1 and newer). No new session will be created after user authentication, but it will change session id.

When session fixation protection occurs, it results in a SessionFixationProtectionEvent being published in the application context

3. How Spring Security Session Fixation Works?

We know by default spring security provides a session fixation protection and we can also customize it as per our need. It’s also equally important that we understand how this protection works internally with Spring security. Spring security uses the following classes to to handle this.

SessionManagementFilter.
SessionAuthenticationStrategy

3.1 SessionManagementFilter

The SessionManagementFilter checks if the user is newly authenticated and if it’s authenticated, it will hand over the work to the SessionAuthenticationStrategy to determine what to do with the session (e.g. should be migrated or new session created. We can control this through the SessionManagement). Here is a code snippet from the SessionManagementFilter filter :

if (!securityContextRepository.containsContext(request)) {
    Authentication authentication = SecurityContextHolder.getContext()
        .getAuthentication();

    if (authentication != null && !trustResolver.isAnonymous(authentication)) {
        // The user has been authenticated during the current request, so call the
        // session strategy
        try {
            sessionAuthenticationStrategy.onAuthentication(authentication,
                request, response);
        }

        // other code
    }
}

The filter checks the SecurityContextRepository to determine if the user is authenticated.
If it’s a new authentication, the filter will call the session strategy to decide which session authentication strategy should be executed (newSession or migrateSession etc).
If the user is not currently authenticated, the filter will check whether an invalid session ID has been requested (because of a timeout, for example) and will invoke the configured InvalidSessionStrategy.

3.2 SessionAuthenticationStrategy

This is an interface which determine which spring security session fixation policy should be used once the user is authenticated. There are different strategies available OOTB with spring security, and they will trigger based on the configurations. For example, the SessionFixationProtectionStrategy will handle both the following use cases.

migrateSession() and copy all attributes of the existing session.
newSession(), they copy no attributes from old session.

When using this, please be aware of the following potential issues which can cause some issue and they are hard to debug:

If you are using the HttpSessionBindingListener and using it in the custom object, copy session attribute can cause some issues.
An example is the use of Spring session-scoped beans, where the initial removal of the bean from the session will cause the DisposableBean interface to be invoked, in the assumption that the bean is no longer required.
Keep these points in mind when you are designing the security for your application.

Summary

In this article, we discussed the Spring Security session fixation protection. The source code for this article is available on GitHub as part of the Spring security tutorial. To summarize, we learned:

What is session fixation issue?
How session fixation attacks works?
what is Spring security session fixation protection and different options?
How the session fixation works internally in spring security?