Year Of Security for Java – Week 2 – Error Handling in web.xml

No Gravatar

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 – 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.




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.


Be Sociable, Share!

Technorati Tags: , , ,