John Melton's Weblog
Java, Security and Technology
Java, Security and Technology
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.
15
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.
References
———–
http://software-security.sans.org/blog/2010/08/11/security-misconfigurations-java-webxml-files
What is it and why do I care?
I’ve already discussed this particular entry in more detail as it’s part of the OWASP Top 10, so you can find more detail here – http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/. In this article, I’ll just cover the important bits.
Error or exception handling is an important, often ignored, part of any application. There is a lot to be said about the topic in general, but for brevity’s sake, I’m only going to cover a couple of the most critical cases in J2EE web applications.
Essentially, one of the biggest worries about exception handling is that you don’t actually handle the exception. Instead your code or the code of some 3rd party library you’re using allows an exception to bubble up. At that point, once it’s at the boundary of your application and gets to the container, it depends on the specific container / application server you are using as to what semantics are applied in the handling of the exception. Often times, by default, there is a standard error page applied and the exception stack trace is simply printed on the screen in all it’s glory. This is clearly a problem in that it gives attackers a lot of information about the system, and can certainly lead to further attacks.
What should I do about it?
Handling this issue is fairly straightforward. The basic advice is to provide error handlers for at least java.lang.Throwable (catches any Java exceptions or errors) and provide more specific handlers for specific exceptions as well as http error codes, the most common being 404 and 500. An example snippet that can be applied to the web.xml is below:
Note: error.jsp page should be generic and provide a canned response message of some type with no detail that could help an attacker fingerprint the app in any way.
404 /error.jsp 500 /error.jsp java.lang.Throwable /error.jsp
There’s plenty more to handling exceptions in your application, but from a security perspective, catching Throwable’s and the specified error codes should do fairly well for you.
References
———–
http://software-security.sans.org/blog/2010/08/11/security-misconfigurations-java-webxml-files
http://www.jtmelton.com/2010/06/02/the-owasp-top-ten-and-esapi-part-7-information-leakage-and-improper-error-handling/
