Reducing information disclosure in Tomcat error pa

问题:

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

回答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.

回答2:

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

回答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

回答4:

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.

回答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..