Security Considerations

+ + &project; + + + Security Considerations + + + + +

Tomcat is configured to be reasonable secure for must use cases by + default. Some environments may require more, or less, secure configurations. + This page is to provide a single point of reference for configuration + options that may impact security and to offer some commentary on the + expected impact of changing those options. The intention is to provide a + list of configuration options that should be considered when assessing the + security of a Tomcat installation.

+ +

Note: Reading this page is not a substitute for reading + and understanding the detailed configuration documentation. Fuller + descriptions of these attributes may be found in the relevant documentation + pages.

+ +

Tomcat configuration should not be the only line of defence. The other + components in the system (operating system, network, database, etc.) should + also be secured. For the operating system, consider limiting the privileges + of the user under which Tomcat is running and limiting access to Tomcat's + files by other users. At the network level, consider using a firewall to + limit both incoming and outgoing connections to only those connections you + expect to be present.

+ +

Tomcat ships with a number of web applications by default. + Vulnerabilities have been discovered in these applications in the past. + Applications that are not required should be removed so the system will not + be at risk if another vulnerability is discovered.

+ +

Enabling the security manager causes web applications to be run in a + sandbox, significantly limiting a web applications ability to perform + malicious actions such as calling System.exit(), establishing network + connections or accessing the file system outside of the web application's + root and temporary directories.

+ +

Tomcat is tested with the security manager enabled but the majority of + Tomcat users do not run with a security manager so Tomcat is not as well + tested in this configuration. There have been, and continue to be, bugs + reported that are triggered by running under a security manager.

+ +

The restrictions imposed by a security manager are likely to break most + applications if the security manager is enabled. The security manager should + not be used without extensive testing. Ideally, the use of a security + manager should be introduced at the start of the development cycle as it can + be time-consuming to track down and fix issues caused by enabling a security + manager for a mature application.

+ +

The default server.xml contains a large number of comments, including + some example component definitions that are commented out. Removing these + comments makes it considerably easier to read and comprehend + server.xml.

If a component type is not listed, then there are no settings for that + type that directly impact security.

+ + + +

Setting the port attribute to -1 disables + the shutdown port.

If the shutdown port is not disabled, a strong password should be + configured for shutdown.

+ + + +

The APR Lifecycle Listener is not stable if compiled on Solaris using + gcc. It using the APR/native connector on Solaris, comppile it with the + Sun Studio compiler.

+ + + +

By default, an HTTP and an AJP connector are configured. Connectors + that will not be used should be removed from server.xml.

+ +

The address attribute may be used to control which IP + address the connector listens on for connections. By default, the + connector listens on all configured IP addresses.

+ +

The allowTrace attribute may be used to enable TRACE + requests which can be useful for debugging. Due to the way some browsers + handle the response from a TRACE request (which exposes the browser to an + XSS attack), support for TRACE requests is disabled by default.

+ +

The maxPostSize attribute controls the maximum size + of a POST request that will be parsed for parameters. The parameters are + cached for the duration of the request so this is limited to 2MB by + default to reduce exposure to a DOS attack.

+ +

The maxSavePostSize attribute controls the saving of + POST requests during FORM and CLIENT-CERT authentication. The parameters + are cached for the duration of the authentication (that may be many + minutes) so this is limited to 4KB by default to reduce exposure to a DOS + attack.

+ +

The xpoweredBy attribute controls whether or not the + X-Powered-By HTTP header is sent with each request. If sent, the value of + the header contains the Servlet and JSP specification versions, the full + Tomcat version (e.g. Apache Tomcat/7.0.0), the name of the JVM vendor and + the version of the JVM. This header is disabled by default. This header + can provide useful information to both legitimate clients and attackers. +

+ +

The server attribute controls the value of the Server + HTTP header. The default value of this header for Tomcat 4.1.x, 5.0.x, + 5.5.x, 6.0.x and 7.0.x is Apache-Coyote/1.1. This header can provide + limited information to both legitimate clients and attackers.

+ +

The SSLEnabled, scheme and + secure attributes may all be independently set. These are + normally used when Tomcat is located behind a reverse proxy and the proxy + is connecting to Tomcat via http or https. They allow Tomcat to see the + SSL attributes of the connections between the client and the proxy rather + than the proxy and Tomcat. For example, the client may connect to the + proxy over https but the proxy connects to Tomcat using http. If it is + necessary for Tomcat to be able to distinguish between secure and + non-secure connections received by a proxy, the proxy must use separate + connectors to pass secure and non-secure requests to Tomcat. If the + proxy uses AJP then the SSL attributes of the client conenction are + passed via the AJP protocol and separate connectors are not needed.

+ +

The tomcatAuthentication attribute is used with the + AJP connectors to determine if Tomcat should authenticate the user or if + authentication can be delegated to the reverse proxy that will then pass + the authenticated username to Tomcat as part of the AJP protocol.

+ +

The allowUnsafeLegacyRenegotiation attribute provides + a workaround for + + CVE-2009-3555, a TLS man in the middle attack. This workaround applies + to the BIO connector. It is only necessary if the underlying SSL + implementation is vulnerable to CVE-2009-3555. For more information on the + current state of this vulnerability and the work-arounds available see the + Tomcat 7 security + page.

+ + + +

The host element controls deployment. Automatic deployment allows for + simpler management but also makes it easier for an attacker to deploy a + malicious application. Automatic deployment is controlled by the + autoDeploy and deployOnStartup + attributes. If both are false, only Contexts defined in + server.xml will be deployed and any changes will require a Tomcat restart. +

+ +

In a hosted environment where web applications may not be trusted, set + the deployXml attribute to false to ignore any + context.xml packaged with the web application that may try to assigned + increased privileges to the web application.

+ + + +

The crossContext attribute controls if a context is + allowed to access the resources of another context. It is + false by default and should only be changed for trusted web + applications.

+ +

The privileged attribute controls if a context is + allowed to use container provided servlets like the Manager servlet. It is + false by default and should only be changed for trusted web + applications.

+ +

The allowLinking attribute controls if a context is + allowed to use linked files. If enabled and the context is undeployed, the + links will be followed when deleting the context resources. To avoid this + behaviour, use the aliases attribute. Changing this + setting from the default of false on case insensitive + operating systems (this includes Windows) will disable a number of + security and allow, amongst other things, direct access to the WEB-INF + directory.

+ + + +

It is strongly recommended that an AccessLogValve is configured. These + are normally configured per host but may also be configured per engine or + per context as required.

+ +

Any administrative application should be protected by a + RemoteAddressValve. (Note that this Valve is also available as a Filter). + The allow attribute should be used to limit access to a set of known + trusted hosts.

+ +

The default ErrorReportValve includes the Tomcat version number in the + response sent to clients. To avoid this, custom error handling can be + configured within each web application. Alternatively, the version number + can be changed by creating the following file in + CATALINA_HOME/lib/org/apache/catalina/util/ServerInfo.properties with the + content as follows: + +server.info=Apache Tomcat/7.0.x + + Modify the values as required. Note that this will also change the version + number reported in some of the management tools and may make it harder to + determine the real version installed. The CATALINA_HOME/bin/version.bat|sh + script will still report the version number.

+ +

The default ErrorReportValve can display stack traces and/or JSP + source code to clients when an error occurs. To avoid this, custom error + handling can be configured within each web application.

+ + + +

The MemoryRealm is not intended for production use as any changes to + tomcat-users.xml require a restart of Tomcat to take effect.

+ +

The JDBCRealm is not recommended for production use as it single + threaded for all authentication and authorisation options. Use the + DataSourceRealm instead.

+ +

The UserDatabaseRealm is not intended for large-scale installations. It + is intended for small-scale, relatively static environments.

+ +

The JAASRealm is not widely used and therefore the code is not as + mature as the other realms. Additional testing is recommended before using + this realm.

+ +

By default, the realms not not implement any form of account lock-out. + This means that brute force attacks can be successful. To prevent a brute + force attack, the chosen realm should be wrapped in a LockOutRealm.

+ + + +

The manager component is used to generate session IDs.

+ +

The default entropy value has been shown to generate predictable values + under certain conditions. For more secure session generation, this should + be set to a long string. This is done automatically if the APR/native + library is installed, a random value will be obtained from APR.

+ +

The class used to generate random session IDs may be changed by using + the randomClass attribute.

+ +

The length of the session ID may be changed by using the + sessionIdLength attribute.

+ +

Setting org.apache.catalina.connector.RECYCLE_FACADES + system property to true will cause a new facade object to be + created for each request. This reduces the chances of a bug in an + application exposing data from one request to another.

+ +

The + org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH and + org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH + system properties allow non-standard parsing of the request URI. Using + these options when behind a reverse proxy may enable an attacker to bypass + any security constraints enforced by the proxy.

+ +

The + org.apache.catalina.connector.Response.ENFORCE_ENCODING_IN_GET_WRITER + has security implications if disabled. Many user agents, in + breach of RFC2616, try and guess the character encoding of text media + types when the specification mandated default of ISO-8859-1 should be + used. If the response contains characters that are safe for ISO-8859-1 + but trigger an XSS if interpreted as UTF-7, some browsers will use UTF-7 + and trigger an XSS vulnerability.

+ +

The DefaultServlet is configured with readonly set to + true. Changing this to false allows clients to + delete or modify static resources on the server and to upload new + resources. This should not normally be changed without requiring + authentication.

+ +

The DefaultServlet is configured with listings set to + false. This isn't because allowing directory listings is + considered unsafe but because generating listings of directories with + thousands of files can consume significant CPU leading to a DOS attack. +

+ +

BASIC and FORM authentication pass user names and passwords in clear + text. Web applications using these authentication mechanisms with clients + connecting over untrusted networks should use SSL.

+ +

The session cookie for a session with an authenticated user are nearly + as useful as the user's password to an attacker and in nearly all + circumstances should be afforded the same level of protection as the + password itself. This usually means authenticating over SSL and continuing + to use SSL until the session ends.

+ + +