What is it and why should I care?
A session timeout is an important security control for any application. It specifies the length of time that an application will allow a user to remain logged in before forcing the user to re-authenticate. There are 2 types: Soft Session Timeouts (today’s topic) and Hard Session Timeouts (I’ll cover this next week).
A soft session timeout is applied when the user does not interact with the system for a period of time.
As an example, lets say we have a system where:
1. Access to the application requires authentication
2. Attempting to access any portion of the application except login (and change/reset pw, etc.) redirects you to the login page.
3. A user logs into your system and walks away for 20 minutes and you have a 15 minute timeout
The net effect of this will be that the next interaction this user has with the system will then redirect them to the login page.
The section above shows what a soft session timeout is and does, but what is it protecting against? There are many issues that are related (authentication,authorization,auditing,session hijacking, etc.), but one of the primary issues is CSRF. By forcing a reasonably low session timeout, you add another security control that increases the difficulty of launching CSRF style attacks. Essentially, any attack that attempts to exploit the fact that the user is logged in is now either prevented or complicated by using this simple control.
What should I do about it?
Like many security controls, there is a tradeoff with functionality related to session timeouts. Many popular web applications that we use have no soft session timeout configured, because they don’t want to trouble a user with an extra step of logging in repeatedly. As in other situations, this is a risk decision to make things less secure for your users in order to make things simpler and easier for them. If you have an application that protects sensitive data, or your users (or you) have a lower threshold of pain with risk decisions, you should opt for including a soft (and hard – see next week) session timeout.
In Java, there are several ways you can do this.
Option 1: Set the timeout in the web.xml
By far the most popular option, this is simple and allows you to configure this without having to set it in code. An example snippet showing a 15 minute timeout is below.
Option 2: Allow the app server to set the session timeout
This could mean that you allow the default (30 minutes for most app servers) or that you set the value specifically in your container. Either way, this is an option.
Option 3: Set timeout in code
This option allows you the ability to encode this setting in code. This does allow you the additional flexibility of setting differet timeouts for different users since it’s set on the session and not globally, but it’s far less common than it’s web.xml alternative
httpSession.setMaxInactiveInterval(15*60); // set in seconds
Option 4: SSO sets the timeout
This is not a Java-only option, but still should be mentioned. Many enterprises use large single sign-on (SSO) identity systems to control access to applications. Many of these systems allow you to set the timeout for an application.
As you can see, the soft session timeout is a useful security control. It allows you to have another layer of protection for your application and your users.