HOWTO: Suppress Server Identity in Tomcat

Note: This HOWTO consoldates posts from two separate blog entries of mine involving the removal of information disclosure vulnerabilities in Apache Tomcat. Although centered around Tomcat versions 6.0 and 7.0, these techniques can also be applied to JBoss.

Introduction

Information Disclosure vulnerabilities are issues that provide an attacker with configuration and/or version details on the web container or web applications running inside the container. The concern these details raise is that the more information the attacker has about your web application or app server, the easier it is for the attacker to come up with ways to breach the service.

The most common types of information disclosure vulnerabilities associated with tomcat found by security auditors and scanning utilities are those that list server type and server version information. The two most-frequently reported information disclosure vulnerabilities involve the Tomcat version being reported in the Server HTTP Response header and default error pages that report server type and version details.

How To Modify the Server Header

You can modify your tomcat server.xml and add a "server" option and set it to whatever you want. The server option should be set for any http or ssl connectors that you have running. For example, below is a sample HTTP Connector configuration from an example server.xml file:

<Connector port="8080" maxHttpHeaderSize="8192"
     maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
     enableLookups="false" redirectPort="8443" acceptCount="100"
     connectionTimeout="20000" disableUploadTimeout="true" />

Add a server directive like the following:

<Connector port="8080" maxHttpHeaderSize="8192"
     maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
     enableLookups="false" redirectPort="8443" acceptCount="100"
     connectionTimeout="20000" disableUploadTimeout="true"
     server="Apache Tomcat">

How To Remove Tomcat Server Version Details from Default Error Pages

Unfortunately, there is no easy configuration file directive change you can make because the defaults are compiled into tomcat. One could modify a tomcat source distribution and re-compile but most administrators may be uncomfortable building their own Tomcat distributions. The tomcat documentation suggests you design and deploy your own custom error pages, then modify various web.xml files in order to point users to those custom error pages using the error-page directives.

If your web application is deployed inside the ROOT webapp, you only need to modify the web.xml file located in your $CATALINA_HOME/webapps/ROOT/ directory. If you deployed your webapp to ROOT, any valid error response will inherit the custom error. This changes however if additional webapps are deployed with separate contexts. In these scenarios, each webapp's web.xml would need to be modified to point to your custom error pages. For example, if you have set custom error-page directives in the ROOT webapp's web.xml and do not have any separate web applications deployed, all 404's will return the 404 custom error. If you deploy an application called "newapp", then any bad requests sent to /newapp will need to be handled with a custom error defined in that application's web.xml. Bad requests made outside of /newapp will still be handled as expected by the ROOT app's web.xml configuration until you add an additional webapp. In this case, you would need to add another set of error-page directives to the new app's web.xml

Using a configuration where the webapp is deployed into the Tomcat ROOT context and assuming you have a custom error 500 and 404 page already developed, you would add the following to your ROOT web applications's web.xml configuration, which is typically located in $CATALINA_HOME/webapps/ROOT/:

<error-page>
  <error-code>500</error-code>
  <location>/errors/500.html</location>
</error-page>
<error-page>
  <error-code>404</error-code>
  <location>/errors/404.html</location>
</error-page>

Test by sending a request for a non-existent file to your tomcat instance and your custom error page will display instead.

Bonus: How To Remove the X-Powered-By Header in Tomcat

In order to suppress the X-Powered-By header in Tomcat 6.0 and 7.0 you can make a very easy change to your tomcat server.xml file. Edit the server.xml file located in ${tomcat.home}/conf/. Add the property named: xpoweredby to the HTTP Connector section and set its value to false. Restart the server and you're all set.