No matter how much security is built in the application, if your configuration is not up to bar, I can safely tell you that it does not really matter how much security is in the application. As the old saying goes: it is as secure as the weakest link, so don’t let the configuration be your weakest link. Let’s have a closer look at web.xml, this is by no means a detailed list of security related settings in web.xml.

1- Session timeout: the amount of inactivity time after which the user will have to login again. A lot of application now offers the user an extended login time so that the user doesn’t have to relogin.

This is bad.

The reason is that it extends the window in which an attacker can launch session-related attack, for example session hijacking, cross-site request forgery and clickjacking. The amount of session timeout shouldn’t be more than 30 minutes of inactivity, preferably less.

2- Error pages: custom error pages in web.xml in my opinion is the most underutilized safety net in J2EE applications. You need to change how you think about custom error pages. Think of them as your safety net, what keeps you in control even when you screw up as a developer and at the same time they are the most decent thing you can do to your user instead of those ugly stack-trace-exception-jargon-full pages.

The problem is that exceptions happens and when they happen they reveal a lot to the attacker. From the stack trace, the attacker will know what frameworks the application is built upon, which database is being used and maybe a bit about operating system too. Now the attacker can use this information to launch attacks against these system or use weaknesses in these systems to get to your application.

3- Welcome file list: The problem with these files is that they are publicly accessible, if an attacker running his tools and scanning sites, these are the pages that will appear on his radar. Why? because they don’t need authentication. Of course, any other page that does not need authentication in your application will have the same problem, but these pages are easier to discover because your application gladly offer them to the attacker.

Make sure you are not leaking information in there. These pages are publicly accessible and can be leaking information or have any major vulnerabilities in them such as cross-site scripting.

4- Security constraint: This is where you can easily harden your application against HTTP Verb Tampering. You only need to allow the HTTP methods you want to allow and disallow everything else.

Now, there are more to web.xml than the above but starting with these four would help in mitigating a bunch of threats in only a few minutes of implementation.

5- Setting the secure flag:

Setting the secure flag on session cookies simply tell the browser not to send the cookie unless the connection is encrypted. This will prevent against situation when some pages might not be encrypted or more importantly against phishing attacks. Here is how it looks like in web.xml

<session-config>
  <cookie-config>
    <secure>true</secure>
  </cookie-config>
</session-config>

This is only available in Servlets 3.0 though. If you are using earlier versions, sorry you are out of luck.

White Paper - Proving Adherence to Software Security Best Practices

White Paper - Proving Adherence to Software Security Best Practices

Industry standards and the best practices for developing secure software. Please provide your email and name to receive your copy.

Success! Your copy is on the way.