Gecko [ edgpens.lpkmn.gov.my ]

Name	Size	Permission
WEB-INF	[ DIR ]	drwxrwxrwx
annotationapi	[ DIR ]	drwxrwxrwx
api	[ DIR ]	drwxrwxrwx
appdev	[ DIR ]	drwxrwxrwx
architecture	[ DIR ]	drwxrwxrwx
config	[ DIR ]	drwxrwxrwx
elapi	[ DIR ]	drwxrwxrwx
images	[ DIR ]	drwxrwxrwx
jspapi	[ DIR ]	drwxrwxrwx
servletapi	[ DIR ]	drwxrwxrwx
tribes	[ DIR ]	drwxrwxrwx
websocketapi	[ DIR ]	drwxrwxrwx
BUILDING.txt	17.97 KB	-rw-rw-rw-
RELEASE-NOTES.txt	9.37 KB	-rw-rw-rw-
RUNNING.txt	17.33 KB	-rw-rw-rw-
aio.html	22.25 KB	-rw-rw-rw-
apr.html	15.53 KB	-rw-rw-rw-
balancer-howto.html	8.06 KB	-rw-rw-rw-
building.html	19.12 KB	-rw-rw-rw-
cgi-howto.html	14.12 KB	-rw-rw-rw-
changelog.html	1.17 MB	-rw-rw-rw-
class-loader-howto.html	20.53 KB	-rw-rw-rw-
cluster-howto.html	46.48 KB	-rw-rw-rw-
comments.html	11.11 KB	-rw-rw-rw-
connectors.html	9.2 KB	-rw-rw-rw-
default-servlet.html	18.66 KB	-rw-rw-rw-
deployer-howto.html	24.29 KB	-rw-rw-rw-
developers.html	8.8 KB	-rw-rw-rw-
extras.html	11.79 KB	-rw-rw-rw-
host-manager-howto.html	16.8 KB	-rw-rw-rw-
html-host-manager-howto.html	15.19 KB	-rw-rw-rw-
html-manager-howto.html	33.65 KB	-rw-rw-rw-
index.html	16.88 KB	-rw-rw-rw-
introduction.html	19.73 KB	-rw-rw-rw-
jasper-howto.html	24.59 KB	-rw-rw-rw-
jdbc-pool.html	73.16 KB	-rw-rw-rw-
jndi-datasource-examples-howto...	38.54 KB	-rw-rw-rw-
jndi-resources-howto.html	55.82 KB	-rw-rw-rw-
logging.html	36.06 KB	-rw-rw-rw-
manager-howto.html	78.01 KB	-rw-rw-rw-
maven-jars.html	8.67 KB	-rw-rw-rw-
mbeans-descriptors-howto.html	8.79 KB	-rw-rw-rw-
mbeans-descriptors.dtd	11.04 KB	-rw-rw-rw-
monitoring.html	44.15 KB	-rw-rw-rw-
proxy-howto.html	13.69 KB	-rw-rw-rw-
realm-howto.html	64.14 KB	-rw-rw-rw-
security-howto.html	41.64 KB	-rw-rw-rw-
security-manager-howto.html	32.25 KB	-rw-rw-rw-
setup.html	15.17 KB	-rw-rw-rw-
ssi-howto.html	21.3 KB	-rw-rw-rw-
ssl-howto.html	43.15 KB	-rw-rw-rw-
virtual-hosting-howto.html	13.93 KB	-rw-rw-rw-
web-socket-howto.html	18.17 KB	-rw-rw-rw-
windows-auth-howto.html	25.28 KB	-rw-rw-rw-
windows-service-howto.html	25.36 KB	-rw-rw-rw-

Code Editor : security-howto.html

<html><head><META http-equiv="Content-Type" content="text/html; charset=iso-8859-1"><title>Apache Tomcat 7 (7.0.107) - Security Considerations</title><style type="text/css" media="print">
 .noPrint {display: none;}
 td#mainBody {width: 100%;}
</style><style type="text/css">
code {background-color:rgb(224,255,255);padding:0 0.1em;}
code.attributeName, code.propertyName {background-color:transparent;}

table {
 border-collapse: collapse;
 text-align: left;
}
table *:not(table) {
 /* Prevent border-collapsing for table child elements like <div> */
 border-collapse: separate;
}

th {
  text-align: left;
}

div.codeBox pre code, code.attributeName, code.propertyName, code.noHighlight, .noHighlight code {
 background-color: transparent;
}
div.codeBox {
 overflow: auto;
 margin: 1em 0;
}
div.codeBox pre {
 margin: 0;
 padding: 4px;
 border: 1px solid #999;
 border-radius: 5px;
 background-color: #eff8ff;
 display: table; /* To prevent <pre>s from taking the complete available width. */
 /*
 When it is officially supported, use the following CSS instead of display: table
 to prevent big <pre>s from exceeding the browser window:
 max-width: available;
 width: min-content;
 */
}

div.codeBox pre.wrap {
  white-space: pre-wrap;
}

table.defaultTable tr, table.detail-table tr {
    border: 1px solid #CCC;
}

table.defaultTable tr:nth-child(even), table.detail-table tr:nth-child(even) {
    background-color: #FAFBFF;
}

table.defaultTable tr:nth-child(odd), table.detail-table tr:nth-child(odd) {
    background-color: #EEEFFF;
}

table.defaultTable th, table.detail-table th {
  background-color: #88b;
  color: #fff;
}

table.defaultTable th, table.defaultTable td, table.detail-table th, table.detail-table td {
  padding: 5px 8px;
}

p.notice {
 border: 1px solid rgb(255, 0, 0);
 background-color: rgb(238, 238, 238);
 color: rgb(0, 51, 102);
 padding: 0.5em;
 margin: 1em 2em 1em 1em;
}
</style></head><body bgcolor="#ffffff" text="#000000" link="#525D76" alink="#525D76" vlink="#525D76"><table border="0" width="100%" cellspacing="0"><tr><td><a href="https://tomcat.apache.org/"><img src="./images/tomcat.gif" align="right" alt="
 The Apache Tomcat Servlet/JSP Container
 " border="0"></a></td><td><h1>Apache Tomcat 7</h1>Version 7.0.107, Nov 18 2020</td><td><a href="http://www.apache.org/"><img src="./images/asf-logo.svg" align="right" alt="Apache Logo" border="0" style="width: 266px;height: 83px;"></a></td></tr></table><table border="0" width="100%" cellspacing="4"><tr><td colspan="2"><hr noshade size="1"></td></tr><tr><td width="20%" valign="top" nowrap class="noPrint">Links<ul><li><a href="index.html">Docs Home</a></li><li><a href="https://wiki.apache.org/tomcat/FAQ">FAQ</a></li><li><a href="#comments_section">User Comments</a></li></ul>User Guide<ul><li><a href="introduction.html">1) Introduction</a></li><li><a href="setup.html">2) Setup</a></li><li><a href="appdev/index.html">3) First webapp</a></li><li><a href="deployer-howto.html">4) Deployer</a></li><li><a href="manager-howto.html">5) Manager</a></li><li><a href="host-manager-howto.html">6) Host Manager</a></li><li><a href="realm-howto.html">7) Realms and AAA</a></li><li><a href="security-manager-howto.html">8) Security Manager</a></li><li><a href="jndi-resources-howto.html">9) JNDI Resources</a></li><li><a href="jndi-datasource-examples-howto.html">10) JDBC DataSources</a></li><li><a href="class-loader-howto.html">11) Classloading</a></li><li><a href="jasper-howto.html">12) JSPs</a></li><li><a href="ssl-howto.html">13) SSL/TLS</a></li><li><a href="ssi-howto.html">14) SSI</a></li><li><a href="cgi-howto.html">15) CGI</a></li><li><a href="proxy-howto.html">16) Proxy Support</a></li><li><a href="mbeans-descriptors-howto.html">17) MBeans Descriptors</a></li><li><a href="default-servlet.html">18) Default Servlet</a></li><li><a href="cluster-howto.html">19) Clustering</a></li><li><a href="balancer-howto.html">20) Load Balancer</a></li><li><a href="connectors.html">21) Connectors</a></li><li><a href="monitoring.html">22) Monitoring and Management</a></li><li><a href="logging.html">23) Logging</a></li><li><a href="apr.html">24) APR/Native</a></li><li><a href="virtual-hosting-howto.html">25) Virtual Hosting</a></li><li><a href="aio.html">26) Advanced IO</a></li><li><a href="extras.html">27) Additional Components</a></li><li><a href="maven-jars.html">28) Mavenized</a></li><li><a href="security-howto.html">29) Security Considerations</a></li><li><a href="windows-service-howto.html">30) Windows Service</a></li><li><a href="windows-auth-howto.html">31) Windows Authentication</a></li><li><a href="jdbc-pool.html">32) Tomcat's JDBC Pool</a></li><li><a href="web-socket-howto.html">33) WebSocket</a></li></ul>Reference<ul><li><a href="RELEASE-NOTES.txt">Release Notes</a></li><li><a href="config/index.html">Configuration</a></li><li><a href="api/index.html">Tomcat Javadocs</a></li><li><a href="servletapi/index.html">Servlet Javadocs</a></li><li><a href="jspapi/index.html">JSP 2.2 Javadocs</a></li><li><a href="elapi/index.html">EL 2.2 Javadocs</a></li><li><a href="websocketapi/index.html">WebSocket 1.1 Javadocs</a></li><li><a href="annotationapi/index.html">Common Annotations 1.1 Javadocs</a></li><li><a href="https://tomcat.apache.org/connectors-doc/">JK 1.2 Documentation</a></li></ul>Apache Tomcat Development<ul><li><a href="building.html">Building</a></li><li><a href="changelog.html">Changelog</a></li><li><a href="https://wiki.apache.org/tomcat/TomcatVersions">Status</a></li><li><a href="developers.html">Developers</a></li><li><a href="architecture/index.html">Architecture</a></li><li><a href="tribes/introduction.html">Tribes</a></li></ul></td><td width="80%" valign="top" align="left" id="mainBody"><h1>Security Considerations</h1><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="Table of Contents"></a><a name="Table_of_Contents">Table of Contents</a></td></tr><tr><td><blockquote>
<ul><li><a href="#Introduction">Introduction</a></li><li><a href="#Non-Tomcat_settings">Non-Tomcat settings</a><ol><li><a href="#JMX">JMX</a></li></ol></li><li><a href="#Default_web_applications">Default web applications</a><ol><li><a href="#Default_web_applications/General">General</a></li><li><a href="#ROOT">ROOT</a></li><li><a href="#Documentation">Documentation</a></li><li><a href="#Examples">Examples</a></li><li><a href="#Default_web_applications/Manager">Manager</a></li><li><a href="#Host_Manager">Host Manager</a></li><li><a href="#Securing_Management_Applications">Securing Management Applications</a></li></ol></li><li><a href="#Security_manager">Security manager</a></li><li><a href="#server.xml">server.xml</a><ol><li><a href="#server.xml/General">General</a></li><li><a href="#Server">Server</a></li><li><a href="#Listeners">Listeners</a></li><li><a href="#Connectors">Connectors</a></li><li><a href="#Host">Host</a></li><li><a href="#Context">Context</a></li><li><a href="#Valves">Valves</a></li><li><a href="#Realms">Realms</a></li><li><a href="#server.xml/Manager">Manager</a></li><li><a href="#Cluster">Cluster</a></li></ol></li><li><a href="#System_Properties">System Properties</a></li><li><a href="#web.xml">web.xml</a></li><li><a href="#General">General</a></li></ul>
</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="Introduction">Introduction</a></td></tr><tr><td><blockquote>
 Tomcat is configured to be reasonably secure for most 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.
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="Non-Tomcat settings"></a><a name="Non-Tomcat_settings">Non-Tomcat settings</a></td></tr><tr><td><blockquote>
 Tomcat configuration should not be the only line of defense. The other
 components in the system (operating system, network, database, etc.) should
 also be secured.
 Tomcat should not be run under the root user. Create a dedicated user for
 the Tomcat process and provide that user with the minimum necessary
 permissions for the operating system. For example, it should not be possible
 to log on remotely using the Tomcat user.
 File permissions should also be suitably restricted. In the
 <code>.tar.gz</code> distribution, files and directories are not world
 readable and the group does not have write access. On Unix like operating
 systems, Tomcat runs with a default umask of <code>0027</code> to maintain
 these permissions for files created while Tomcat is running (e.g. log files,
 expanded WARs, etc.).
 Taking the Tomcat instances at the ASF as an example (where
 auto-deployment is disabled and web applications are deployed as exploded
 directories), the standard configuration is to have all Tomcat files owned
 by root with group Tomcat and whilst owner has read/write privileges, group
 only has read and world has no permissions. The exceptions are the logs,
 temp and work directory that are owned by the Tomcat user rather than root.
 This means that even if an attacker compromises the Tomcat process, they
 can't change the Tomcat configuration, deploy new web applications or
 modify existing web applications. The Tomcat process runs with a umask of
 007 to maintain these permissions.
 At the network level, consider using a firewall to limit both incoming
 and outgoing connections to only those connections you expect to be
 present.

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="JMX">JMX</a></td></tr><tr><td><blockquote>
 The security of the JMX connection is dependent on the implementation
 provided by the JRE and therefore falls outside the control of Tomcat.

Typically, access control is very limited (either read-only to
 everything or read-write to everything). Tomcat exposes a large amount
 of internal information and control via JMX to aid debugging, monitoring
 and management. Given the limited access control available, JMX access
 should be treated as equivalent to local root/admin access and restricted
 accordingly.

The JMX access control provided by most (all?) JRE vendors does not
 log failed authentication attempts, nor does it provide an account
 lock-out feature after repeated failed authentications. This makes a
 brute force attack easy to mount and difficult to detect.

Given all of the above, care should be taken to ensure that, if used,
 the JMX interface is appropriately secured. Options you may wish to
 consider to secure the JMX interface include:

<ul>
 <li>configuring a strong password for all JMX users;</li>
 <li>binding the JMX listener only to an internal network;</li>
 <li>limiting network access to the JMX port to trusted clients; and</li>
 <li>providing an application specific health page for use by external
 monitoring systems.</li>
 </ul>
 </blockquote></td></tr></table>

</blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="Default web applications"></a><a name="Default_web_applications">Default web applications</a></td></tr><tr><td><blockquote>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Default web applications/General"></a><a name="Default_web_applications/General">General</a></td></tr><tr><td><blockquote>
 Tomcat ships with a number of web applications that are enabled 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.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="ROOT">ROOT</a></td></tr><tr><td><blockquote>
 The ROOT web application presents a very low security risk but it does
 include the version of Tomcat that is being used. The ROOT web application
 should normally be removed from a publicly accessible Tomcat instance, not
 for security reasons, but so that a more appropriate default page is shown
 to users.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Documentation">Documentation</a></td></tr><tr><td><blockquote>
 The documentation web application presents a very low security risk but
 it does identify the version of Tomcat that is being used. It should
 normally be removed from a publicly accessible Tomcat instance.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Examples">Examples</a></td></tr><tr><td><blockquote>
 The examples web application should always be removed from any security
 sensitive installation. While the examples web application does not
 contain any known vulnerabilities, it is known to contain features
 (particularly the cookie examples that display the contents of all
 received and allow new cookies to be set) that may be used by an attacker
 in conjunction with a vulnerability in another application deployed on the
 Tomcat instance to obtain additional information that would otherwise be
 unavailable.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Default web applications/Manager"></a><a name="Default_web_applications/Manager">Manager</a></td></tr><tr><td><blockquote>
 The Manager application allows the remote deployment of web
 applications and is frequently targeted by attackers due to the widespread
 use of weak passwords and publicly accessible Tomcat instances with the
 Manager application enabled. The Manager application is not accessible by
 default as no users are configured with the necessary access. If the
 Manager application is enabled then guidance in the section
 Securing Management Applications section should be
 followed.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Host Manager"></a><a name="Host_Manager">Host Manager</a></td></tr><tr><td><blockquote>
 The Host Manager application allows the creation and management of
 virtual hosts - including the enabling of the Manager application for a
 virtual host. The Host Manager application is not accessible by default
 as no users are configured with the necessary access. If the Host Manager
 application is enabled then guidance in the section Securing
 Management Applications section should be followed.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Securing Management Applications"></a><a name="Securing_Management_Applications">Securing Management Applications</a></td></tr><tr><td><blockquote>
 When deploying a web application that provides management functions for
 the Tomcat instance, the following guidelines should be followed:
 <ul>
 <li>Ensure that any users permitted to access the management application
 have strong passwords.</li>
 <li>Do not remove the use of the <a href="config/realm.html#LockOut_Realm_-_org.apache.catalina.realm.LockOutRealm">LockOutRealm</a>
 which prevents brute force attacks against user passwords.</li>
 <li>Uncomment the <a href="config/valve.html#Remote_Address_Filter">RemoteAddrValve</a>
 in <code>/META-INF/context.xml</code> which limits access to
 localhost. If remote access is required, limit it to specific IP
 addresses using this valve.</li>
 </ul>
 </blockquote></td></tr></table>
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="Security manager"></a><a name="Security_manager">Security manager</a></td></tr><tr><td><blockquote>
 Enabling the security manager causes web applications to be run in a
 sandbox, significantly limiting a web application's 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. However, it should be noted that there are
 some malicious actions, such as triggering high CPU consumption via an
 infinite loop, that the security manager cannot prevent.

Enabling the security manager is usually done to limit the potential
 impact, should an attacker find a way to compromise a trusted web
 application . A security manager may also be used to reduce the risks of
 running untrusted web applications (e.g. in hosting environments) but it
 should be noted that the security manager only reduces the risks of
 running untrusted web applications, it does not eliminate them. If running
 multiple untrusted web applications, it is recommended that each web
 application is deployed to a separate Tomcat instance (and ideally separate
 hosts) to reduce the ability of a malicious web application impacting the
 availability of other applications.

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

Enabling the security manager changes the defaults for the following
 settings:
 <ul>
 <li>The default value for the deployXML attribute of the
 Host element is changed to <code>false</code>.</li>
 </ul>
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="server.xml">server.xml</a></td></tr><tr><td><blockquote>
 <table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="server.xml/General">General</a></td></tr><tr><td><blockquote>
 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.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Server">Server</a></td></tr><tr><td><blockquote>
 Setting the port attribute to <code>-1</code> disables
 the shutdown port.
 If the shutdown port is not disabled, a strong password should be
 configured for shutdown.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Listeners">Listeners</a></td></tr><tr><td><blockquote>
 The APR Lifecycle Listener is not stable if compiled on Solaris using
 gcc. If using the APR/native connector on Solaris, compile it with the
 Sun Studio compiler.
 The JNI Library Loading Listener may be used to load native code. It should
 only be used to load trusted libraries.
 The Security Lifecycle Listener should be enabled and configured as appropriate.
 
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Connectors">Connectors</a></td></tr><tr><td><blockquote>
 By default, a non-TLS, HTTP/1.1 connector is configured on port 8080.
 Connectors that will not be used should be removed from server.xml.

The address attribute may be used to control which IP
 address a connector listens on for connections. By default, a 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 discardFacades attribute set to <code>true</code>
 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 encodedSolidusHandling attribute allows
 non-standard parsing of the request URI. Setting this attribute to a
 non-default value when behind a reverse proxy may enable an attacker to
 bypass any security constraints enforced by the proxy.

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 (which may be many
 minutes) so this is limited to 4KB by default to reduce exposure to a DOS
 attack.

The maxParameterCount attribute controls the
 maximum number of parameter and value pairs (GET plus POST) that can
 be parsed and stored in the request. Excessive parameters are ignored.
 If you want to reject such requests, configure a
 <a href="config/filter.html">FailedRequestFilter</a>.

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), 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 to
 8.0.x is Apache-Coyote/1.1. From 8.5.x onwards this header is not set by
 default. 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 connection are
 passed via the AJP protocol and separate connectors are not needed.

The tomcatAuthentication and
 tomcatAuthorization attributes are used with the
 AJP connectors to determine if Tomcat should handle all authentication and
 authorisation or if authentication should be delegated to the reverse
 proxy (the authenticated user name is passed to Tomcat as part of the AJP
 protocol) with the option for Tomcat to still perform authorization.

The allowUnsafeLegacyRenegotiation attribute provides
 a workaround for
 <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555">
 CVE-2009-3555</a>, 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
 <a href="http://tomcat.apache.org/security-7.html">Tomcat 7 security
 page</a>.

The requiredSecret attribute in AJP connectors
 configures shared secret between Tomcat and reverse proxy in front of
 Tomcat. It is used to prevent unauthorized connections over AJP protocol.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Host">Host</a></td></tr><tr><td><blockquote>
 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 <code>false</code>, 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 <code>false</code> to ignore
 any context.xml packaged with the web application that may try to assign
 increased privileges to the web application. Note that if the security
 manager is enabled that the deployXML attribute will
 default to <code>false</code>.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Context">Context</a></td></tr><tr><td><blockquote>
 This applies to <a href="config/context.html">Context</a>
 elements in all places where they can be defined:
 <code>server.xml</code> file,
 default <code>context.xml</code> file,
 per-host <code>context.xml.default</code> file,
 web application context file in per-host configuration directory
 or inside the web application.

The crossContext attribute controls if a context is
 allowed to access the resources of another context. It is
 <code>false</code> 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
 <code>false</code> 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 <code>false</code> on case insensitive
 operating systems (this includes Windows) will disable a number of
 security measures and allow, among other things, direct access to the
 WEB-INF directory.

The sessionCookiePathUsesTrailingSlash can be used to
 work around a bug in a number of browsers (Internet Explorer, Safari and
 Edge) to prevent session cookies being exposed across applications when
 applications share a common path prefix. However, enabling this option
 can create problems for applications with Servlets mapped to
 <code>/*</code>. It should also be noted the RFC6265 section 8.5 makes it
 clear that different paths should not be considered sufficient to isolate
 cookies from other applications.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Valves">Valves</a></td></tr><tr><td><blockquote>
 It is strongly recommended that an AccessLogValve is configured. The
 default Tomcat configuration includes an AccessLogValve. 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
 RemoteAddrValve (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, you can explicitly
 configure an <a href="config/valve.html">ErrorReportValve</a> and set its
 showServerInfo attribute to <code>false</code>.
 Alternatively, the version number can be changed by creating the file
 CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with
 content as follows:
 <div class="codeBox"><pre><code>server.info=Apache Tomcat/7.0.x</code></pre></div>
 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 correct 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. Alternatively, you
 can explicitly configure an <a href="config/valve.html">ErrorReportValve</a>
 and set its showReport attribute to <code>false</code>.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Realms">Realms</a></td></tr><tr><td><blockquote>
 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 is single
 threaded for all authentication and authorization 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 do 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.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="server.xml/Manager">Manager</a></td></tr><tr><td><blockquote>
 The manager component is used to generate session IDs.

The class used to generate random session IDs may be changed with
 the randomClass attribute.

The length of the session ID may be changed with the
 sessionIdLength attribute.

The persistAuthentication controls whether the
 authenticated Principal associated with the session (if any) is included
 when the session is persisted during a restart or to a Store.
 </blockquote></td></tr></table>

<table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#828DA6"><a name="Cluster">Cluster</a></td></tr><tr><td><blockquote>
 The cluster implementation is written on the basis that a secure,
 trusted network is used for all of the cluster related network traffic. It
 is not safe to run a cluster on a insecure, untrusted network.
 </blockquote></td></tr></table>
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="System Properties"></a><a name="System_Properties">System Properties</a></td></tr><tr><td><blockquote>
 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
 system property has security implications if disabled. Many user
 agents, in breach of RFC2616, try to guess the character encoding of text
 media types when the specification-mandated default of ISO-8859-1 should be
 used. Some browsers will interpret as UTF-7 a response containing characters
 that are safe for ISO-8859-1 but trigger an XSS vulnerability if interpreted
 as UTF-7.
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="web.xml">web.xml</a></td></tr><tr><td><blockquote>
 This applies to the default <code>conf/web.xml</code> file and
 <code>WEB-INF/web.xml</code> files in web applications if they define
 the components mentioned here.

The <a href="default-servlet.html">DefaultServlet</a> is configured
 with readonly set to
 <code>true</code>. Changing this to <code>false</code> 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
 <code>false</code>. 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.

The DefaultServlet is configured with showServerInfo
 set to <code>true</code>. When the directory listings is enabled the Tomcat
 version number is included in the response sent to clients. To avoid this,
 you can explicitly configure a DefaultServlet and set its
 showServerInfo attribute to false.
 Alternatively, the version number can be changed by creating the file
 CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties with
 content as follows:
 <div class="codeBox"><pre><code>server.info=Apache Tomcat/7.0.x</code></pre></div>
 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 correct version number.

The CGI Servlet is disabled by default. If enabled, the debug
 initialisation parameter should not be set to <code>10</code> or higher on a
 production system because the debug page is not secure.

When using the CGI Servlet on Windows with
 <code>enableCmdLineArguments</code> enabled, review the setting of
 <code>cmdLineArgumentsDecoded</code> carefully and ensure that it is
 appropriate for your environment. The default value is secure. Insecure
 configurations may expose the server to remote code execution. Further
 information on the potential risks and mitigations may be found by
 following the links in the <a href="cgi-howto.html">CGI How To</a>.

<a href="config/filter.html">FailedRequestFilter</a>
 can be configured and used to reject requests that had errors during
 request parameter parsing. Without the filter the default behaviour is
 to ignore invalid or excessive parameters.

<a href="config/filter.html">HttpHeaderSecurityFilter</a> can be
 used to add headers to responses to improve security. If clients access
 Tomcat directly, then you probably want to enable this filter and all the
 headers it sets unless your application is already setting them. If Tomcat
 is accessed via a reverse proxy, then the configuration of this filter needs
 to be co-ordinated with any headers that the reverse proxy sets.
 </blockquote></td></tr></table><table border="0" cellspacing="0" cellpadding="2"><tr><td bgcolor="#525D76"><a name="General">General</a></td></tr><tr><td><blockquote>
 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.
 </blockquote></td></tr></table></td></tr><tr><td colspan="2"><hr noshade size="1"></td></tr><tr><td colspan="2"><div align="center">
 Copyright &copy; 1999-2020, Apache Software Foundation
 </div></td></tr></table></body></html>

${this.title}

Code Editor : security-howto.html