Permalink to this page: https://cwiki.apache.org/confluence/x/qyolBg
This FAQ section provides help with some security-related issues. If you hear of a vulnerability or its exploitation, please see the security page.
There have been no public cases of damage done to a company, organization, or individual due to a Tomcat security issue. There have been no documented cases of data loss or application crashes caused by an intruder. While there have been numerous analyses conducted on Tomcat, partially because this is easy to do with Tomcat's source code openly available, there have been only theoretical vulnerabilities found. All of those were addressed even though there were no documented cases of actual exploitation of these vulnerabilities.
That said,
There was once a bug that blindly clicking-trough the Windows installer configured a manager user with blank password (CVE-2009-3548). This was fixed by April 2010 (Tomcat 5.5.29, 6.0.24 and later are safe).
Please see "Security considerations" pages in Tomcat documentation (linked below) for a reference on how access to Management Applications in Tomcat should be secured.
We believe, and the evidence suggests, that Tomcat is more than secure enough for most use-cases. However, like all other components of Tomcat, you can customize any and all of the relevant parts of the server to achieve even higher security. For example, the session manager implementation is pluggable, and even the default implementation has support for pluggable random number generators. If you have a special need that you feel is not met by Tomcat out of the box, consider these customization options. At the same time, please bring up your requirements on the user mailing list, where we'll be glad to discuss it and assist in your approach/design/implementation as needed.
It is also possible to configure Tomcat insecurely. Please see "Security considerations" pages in Tomcat documentation (linked below) for the list of security-sensitive options.
Using OpenSSL to set up your own CA.
See these 2 discussions.
See these threads:
Use security-constraint in web.xml.
The admin and manager application do not provide a default login. Doing so would be a security flaw. You need to edit $CATALINA_HOME/conf/tomcat-users.xml file if you are using the default install. See Configuring Manager Application Access for details.
Note that there exists malware that tries to guess the manager password.
There was once a bug that blindly clicking-trough the Windows installer configured a manager user with blank password (CVE-2009-3548). This was fixed by April 2010 (Tomcat 5.5.29, 6.0.24 and later are safe).
By using the RemoteHostValve
or RemoteAddrValve
. Warning, these valves rely on accurate incoming ip addresses or hostnames. So they can fall victim to spoofing! See also RemoteIpValve
. Valve Reference Link
Fairly easily See the Setup page in the docs for your tomcat release, and read this mailing list post for a complete setup example with permissions etc.
Yes, by numerous organizations and individuals, many times. Try this Google search and you'll see many references, guides, and analyses.
In server.xml
file add a "server" attribute to the Connector element. https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
We have a page dedicated to this topic. Password
See HowTo SSLCiphers.
See Security/Ciphers.
Out of the box - No.
But that doesn't prevent an application deployed to Tomcat from using log4j2. In which case, please use general guidance on various remediations. As of this writing, they include any of these
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
should work tooorg/apache/logging/log4j/core/net/JndiManager$1.class
org/apache/logging/log4j/core/util/JndiCloser.class
org/apache/logging/log4j/core/net/JndiManager$JndiManagerFactory.class
org/apache/logging/log4j/core/lookup/JndiLookup.class
org/apache/logging/log4j/core/net/JndiManager.class
org/apache/logging/log4j/core/selector/JndiContextSelector.class
More details on these CVE's via the ASF blog
JMXProxy is a powerful servlet which has full access to all JMX capabilities. By design, enabling it opens you to a lot of security challenges. The equivalent of enabling generic remote JMX access at the JVM level.
With that in mind, if you enable it: You should at a minimum require an extremely strong password to protect this URL as well restrict the IP client list which may access it. (Ideally restricting it to localhost if possible)