Reducing information disclosure in Tomcat error pages

Question

By default, Tomcat's error pages disclose both the existence of Tomcat and the exact version of the container that's handling the requests. This is nice for development, but in a production context this information is a potential security hole and it would be nice to disable it.

Thus I would like to know what the best (as in most straightforward/comprehensive) solution is to completely suppress Tomcat's default error pages. I am aware of the <error-page> option in web.xml, but it seems to fail on both desired counts, partly because I would have to list the same alternative error page many times (one for each response code I want to handle), and because this strikes me as possibly not 100% robust; if an attacker can somehow get an error code returned that I haven't explicitly listed, they would get the default error page.

Ideally, a simple option to set a universal custom error page, or to flat out disable sending any HTML along with the error code in the default error page, would be best. If neither of those options are possible, I'd be interested in finding out what the typical way to implement this functionality is (bonus points for discussing/showing why those hypothetical options don't exist, since it seems my requirement would be quite standard for anyone using Tomcat in production...).

Solution 1

<error-page> is the right answer, but you don't want to just redirect all error codes to some generic message. You have to think about how you want to handle each error. If you're afraid you might miss one of the codes, check out the constants in the HttpServletResponse interface.

Solution 2

The simplest and most comprehensive way to do this is using the ErrorReportValve - just add the following lines to the Host section of your server.xml (where you should already have the AccessLogValve:

<Valve className="org.apache.catalina.valves.ErrorReportValve"
    showReport="false" 
    showServerInfo="false"/>    

In this way you are hiding the server info and (because of the optional showReport=false) also the stack traces.

You can read more about this in the Security How To and in the documentation of the Error Report Valve.

Solution 3

I agree with Jeremy Stein, that <error-page> is the answer, however I'd like to add 2 points:

1. You should put an <error-page> entry in the CATALINA_HOME/conf/web.xml file, in addition to the application's web.xml file, in case the hacker tries to access URL's in other web-apps such as the default-installed 'manager', 'tomcat', 'examples' etc..

2. If you want to secure the server it's (evidently) not as simple as taking care of these error pages. This link has a list of things you need to do:

https://www.owasp.org/index.php/Securing_tomcat

Solution 4

Some of the errors are sent directly by the container and your application doesn't have a chance to deal with them. For example, when a non-existent resource is requested, the 404 error will be sent. The only way your application can do something about it is to declare the appropriate <error-page> entry in the web.xml.

I agree with Jeremy Stein that the <error-page> is the right answer. After all the error codes aren't unlimited.

Read also the discussion here, about how errors are handled with Spring MVC. I believe that it is most important is to handle your own errors (the exceptions that if they don't get caught will result in a 500 Internal Server Error).

Solution 5

A possible option would be to set up a Servlet Filter, that could redirect error pages to exactly the page you want ... You would only code this once, and it would work for all error codes..

View more solutions

Comments

[Andrzej Doyle]

An interesting approach... I suspect it might be a bit fragile and kill performance as I'd need to parse every single response to try and work out from the raw characters whether it was a default error page or not. Or is there a better way to identify the problem pages?

[CppDude]

@dtsazza Concerning performance, if you compare the dozens instructions implied to the dozen thousands that are involved in the whole processing of the request, it's less than 0.1%. Performance impact is negligible when the code is so high level.

[Andrzej Doyle]

But I kind of do want to - since it's a self-contained webapp, from the user's perspective either things are working or they're not; the actual response they see really can be generic (logs will show technical staff the actual problem plus the HTTP response code is still intact). Accepting your answer anyway, on the basis of the enumeration of response codes that Tomcat may send.

[Tim Cooper]

In the default tomcat installation there are a bunch of webapps installed by default, e.g. 'manager', 'host-manager', 'examples', 'tomcat'. It looks like I need to configure this full set of error codes with each of these webapps, right?

[Tim Cooper]

Oh - I just discovered the CATALINA_HOME/conf/web.xml file. I've put the <error-page>'s in there, but it's still a problem because I can't figure out how to make tomcat find the referenced file (or where to put my error.html file). This means that the hacker sees a different result depending on whether he queries '<host>/tomcat' versus '<host>/foo' which at least discloses that I'm using tomcat.