You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2010/02/11 14:17:07 UTC
svn commit: r908955 - in /tomcat/trunk/webapps/docs: project.xml
security-howto.xml
Author: markt
Date: Thu Feb 11 13:17:05 2010
New Revision: 908955
URL: http://svn.apache.org/viewvc?rev=908955&view=rev
Log:
Convert my ApacheCon securing Tomcat presentation to a how to
Added:
tomcat/trunk/webapps/docs/security-howto.xml (with props)
Modified:
tomcat/trunk/webapps/docs/project.xml
Modified: tomcat/trunk/webapps/docs/project.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/project.xml?rev=908955&r1=908954&r2=908955&view=diff
==============================================================================
--- tomcat/trunk/webapps/docs/project.xml (original)
+++ tomcat/trunk/webapps/docs/project.xml Thu Feb 11 13:17:05 2010
@@ -62,8 +62,11 @@
<item name="23) APR/Native" href="apr.html"/>
<item name="24) Virtual Hosting" href="virtual-hosting-howto.html"/>
<item name="25) Advanced IO" href="aio.html"/>
- <item name="26) Additional Components" href="extras.html"/>
- <item name="27) Mavenized" href="maven-jars.html"/>
+ <item name="26) Additional Components"
+ href="extras.html"/>
+ <item name="27) Mavenized" href="maven-jars.html"/>
+ <item name="28) Security Considerations"
+ href="security-howto.html"/>
</menu>
<menu name="Reference">
Added: tomcat/trunk/webapps/docs/security-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/security-howto.xml?rev=908955&view=auto
==============================================================================
--- tomcat/trunk/webapps/docs/security-howto.xml (added)
+++ tomcat/trunk/webapps/docs/security-howto.xml Thu Feb 11 13:17:05 2010
@@ -0,0 +1,323 @@
+<?xml version="1.0"?>
+<!--
+ Licensed to the Apache Software Foundation (ASF) under one or more
+ contributor license agreements. See the NOTICE file distributed with
+ this work for additional information regarding copyright ownership.
+ The ASF licenses this file to You under the Apache License, Version 2.0
+ (the "License"); you may not use this file except in compliance with
+ the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
+-->
+<!DOCTYPE document [
+ <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="security-howto.html">
+
+ &project;
+
+ <properties>
+ <title>Security Considerations</title>
+ </properties>
+
+<body>
+
+ <section name="Introduction">
+ <p>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.</p>
+
+ <p><strong>Note</strong>: 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.</p>
+ </section>
+
+ <section name="Non-Tomcat settings">
+ <p>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.</p>
+ </section>
+
+ <section name="Default web applications">
+ <p>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.</p>
+ </section>
+
+ <section name="Security manager">
+ <p>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.</p>
+
+ <p>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.</p>
+
+ <p>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.</p>
+ </section>
+
+ <section name="server.xml">
+ <subsection name="General">
+ <p>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.</p>
+ <p>If a component type is not listed, then there are no settings for that
+ type that directly impact security.</p>
+ </subsection>
+
+ <subsection name="Server">
+ <p>Setting the <strong>port</strong> attribute to <code>-1</code> disables
+ the shutdown port.</p>
+ <p>If the shutdown port is not disabled, a strong password should be
+ configured for <strong>shutdown</strong>.</p>
+ </subsection>
+
+ <subsection name="Listeners">
+ <p>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.</p>
+ </subsection>
+
+ <subsection name="Connectors">
+ <p>By default, an HTTP and an AJP connector are configured. Connectors
+ that will not be used should be removed from server.xml.</p>
+
+ <p>The <strong>address</strong> 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.</p>
+
+ <p>The <strong>allowTrace</strong> 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.</p>
+
+ <p>The <strong>maxPostSize</strong> 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.</p>
+
+ <p>The <strong>maxSavePostSize</strong> 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.</p>
+
+ <p>The <strong>xpoweredBy</strong> 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.
+ </p>
+
+ <p>The <strong>server</strong> 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.</p>
+
+ <p>The <strong>SSLEnabled</strong>, <strong>scheme</strong> and
+ <strong>secure</strong> 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.</p>
+
+ <p>The <strong>tomcatAuthentication</strong> 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.</p>
+
+ <p>The <strong>allowUnsafeLegacyRenegotiation</strong> 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>.</p>
+ </subsection>
+
+ <subsection name="Host">
+ <p>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
+ <strong>autoDeploy</strong> and <strong>deployOnStartup</strong>
+ attributes. If both are <code>false</code>, only Contexts defined in
+ server.xml will be deployed and any changes will require a Tomcat restart.
+ </p>
+
+ <p>In a hosted environment where web applications may not be trusted, set
+ the <strong>deployXml</strong> attribute to false to ignore any
+ context.xml packaged with the web application that may try to assigned
+ increased privileges to the web application. </p>
+ </subsection>
+
+ <subsection name="Context">
+ <p>The <strong>crossContext</strong> 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.</p>
+
+ <p>The <strong>privileged</strong> 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.</p>
+
+ <p>The <strong>allowLinking</strong> 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 <strong>aliases</strong> 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 and allow, amongst other things, direct access to the WEB-INF
+ directory.</p>
+ </subsection>
+
+ <subsection name="Valves">
+ <p>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.</p>
+
+ <p>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.</p>
+
+ <p>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:
+ <source>
+server.info=Apache Tomcat/7.0.x
+ </source>
+ 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.</p>
+
+ <p>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.</p>
+ </subsection>
+
+ <subsection name="Realms">
+ <p>The MemoryRealm is not intended for production use as any changes to
+ tomcat-users.xml require a restart of Tomcat to take effect.</p>
+
+ <p>The JDBCRealm is not recommended for production use as it single
+ threaded for all authentication and authorisation options. Use the
+ DataSourceRealm instead.</p>
+
+ <p>The UserDatabaseRealm is not intended for large-scale installations. It
+ is intended for small-scale, relatively static environments.</p>
+
+ <p>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.</p>
+
+ <p>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.</p>
+ </subsection>
+
+ <subsection name="Manager">
+ <p>The manager component is used to generate session IDs.</p>
+
+ <p>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.</p>
+
+ <p>The class used to generate random session IDs may be changed by using
+ the <strong>randomClass</strong> attribute.</p>
+
+ <p>The length of the session ID may be changed by using the
+ <strong>sessionIdLength</strong> attribute.</p>
+ </subsection>
+ </section>
+
+ <section name="System Properties">
+ <p>Setting <strong>org.apache.catalina.connector.RECYCLE_FACADES</strong>
+ system property 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.</p>
+
+ <p>The <strong>
+ org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH</strong> and
+ <strong>org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH</strong>
+ 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.</p>
+
+ <p>The <strong>
+ org.apache.catalina.connector.Response.ENFORCE_ENCODING_IN_GET_WRITER
+ </strong> 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.</p>
+ </section>
+
+ <section name="CATALINA_BASE/conf/web.xml">
+ <p>The DefaultServlet is configured with <strong>readonly</strong> 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.</p>
+
+ <p>The DefaultServlet is configured with <strong>listings</strong> 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.
+ </p>
+ </section>
+
+ <section name="General">
+ <p>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.</p>
+
+ <p>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.</p>
+ </section>
+
+</body>
+</document>
Propchange: tomcat/trunk/webapps/docs/security-howto.xml
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tomcat/trunk/webapps/docs/security-howto.xml
------------------------------------------------------------------------------
svn:keywords = Date Author Id Revision
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org