TechNote (Archived)

Removing sample apps and online documentation from production servers

To help prevent security breaches, you should remove sample applications and online documentation from any production Web server.

When a production Web site (one that is used for mission-critical purposes, as well as any server that is connected to the Internet or other uncontrolled network) is set up and administered, the administrator's goal is to control its security as much as possible. A good way to do this is to remove unused or uncontrolled access points, and to make it as hard as possible for a hypothetical attacker to identify your Web site and the software that drives it.

One good way to accomplish this task is to remove sample applications and online documentation from your production Web servers. Because hypothetical attackers can identify your server software through your applications, removing them helps eliminate this ability. It also denies attackers the ability to exploit any security vulnerabilities. Since it's always possible that a code sample has an unidentified security issue, the more unneccessary applications that you have installed on your production site, the more open you are to possible future attacks.

Removing documentation clearly accomplishes the goal of removing ways for hypothetical attackers to identify your server software. Another reason to remove documentation that is less obvious is that online documentation sometimes includes sample code that is executable.

You should review the configuration of your production servers to determine whether sample applications and documentation were installed by default or installed in a way that was not limited to localhost execution. You should also check whether rolling a development or test server into production brings sample applications and online documentation with it.

For the sake of completeness, known potential vulnerabilities for Macromedia server products are listed here, but keep in mind that it is most secure to be redundant in security research. Macromedia strongly advises you to review current Macromedia Security Bulletins (ASBs) for Macromedia products as well, to make sure that all your information is current and up to date.

ColdFusion 4.0 and Earlier

ASB99-01 and ASB99-02 advised of the issue where sample applications and documentation were installed by default in installations of ColdFusion. Both ASBs contain the ColdFusion 4.0.1 Update, which provided a solution for ColdFusion 4.0, and recommend that administrators of previous versions of ColdFusion simply remove the offending directory.

You should remove the CFDOCS directory. In a typical installation, that directory is at:

web_root/CFDOCS/

ColdFusion 4.0.1 and ColdFusion 4.5.x

In ColdFusion 4.5.x, the documentation and sample applications are not installed by default; you must deliberately enable their installation during the install process if you want them installed. However, it is possible that the documentation and sample applications are installed on a production environment; the production server may have formerly been a development server, for example. In order to secure your server against potential security attacks targeted against these resources, remove the CFDOCS directory. As in the ColdFusion 4.0 and earlier servers, the CFDOCS directory resides in the same location.

You should remove the CFDOCS directory. In a typical installation, that directory resides at:

web_root/CFDOCS/

JRun 2.3

As per ASB00-15, JRun 2.3 sample applications are installed by default and should be removed from all production servers to ensure server security through JRun. In addition, contents of the JRUN_HOME/servlets directory contain components of the sample applications and should also be removed.

To remove sample applications and servlets, remove all non-user-created contents from the following directories:

JRUN_HOME/servlets/
JRUN_HOME/jsm-default/services/jws/htdocs/

NOTE: Do not remove the directories themselves unless you also remove their mappings from the JRun Administrative Interface, and you do not plan to install future content in these directories.

Another aspect of a testing or development server that should be deactivated on JRun production servers is the "invoker" servlet. The invoker servlet makes it very easy for developers to test servlet classes because they do not have to be explictly registered with the JRun application server, but it exposes a security hole for production servers. This servlet allows classes to be invoked by using /servlet/<class name> URLs. This potentially allows attackers to invoke servlets or static code in classes remotely without permission.

To deactivate the invoker servlet from JRun 2.3 production servers, do the following:

Comment out the /servlet/=invoker rule from all copies of the rules.properties file on your JRun 2.3 server.

JRun 3.0

JRun 3.0 sample applications are installed by default, but their execution is locked down to localhost only. Ideally, you should remove sample applications from a production server anyway.

To remove the sample applications in JRun 3.0 do the following:

Start the JRun Management Console (JMC).
In the left side navigation area, click to expand the entry for the JRun Default Server.
Click the entry called Web Applications.
Write down the directory for root dir under the JRun Demo application listed on the right side of the screen, under Applications Currently Available on this Server. You need this information for step 7.
In the application description, click the icon next to JRun Demo that looks like a sheet of paper with a red X drawn on it. This deletes the application from the JRun server.
In the Remove a Web Application screen, make sure the JRun Demo entry is highlighted in the list box, and click the Remove button.
Now that the application is removed from JRun, remove the directory, which you wrote down in step 4, from your server file system.

Additionally, as with JRun 2.3 production servers, another aspect of a testing or development server that should be deactivated on JRun 3.0 production servers is the "invoker" servlet. The invoker servlet makes it very easy for developers to test servlet classes because they do not have to be explictly registered with the JRun application server, but it exposes a security hole for production servers. This servlet allows classes to be invoked by using /servlet/<class name> URLs. This potentially allows attackers to invoke servlets or static code in classes remotely without permission.

To deactivate the invoker servlet from production JRun 3.0 servers, do the following:

Comment out thewebapp.servlet-mapping./servlet=invoker rule from theJRUN_HOME/lib/global.properties file.

Macromedia Spectra 1.0

As per ASB00-04, Macromedia strongly recommends that customers remove all documentation, sample code, example applications, and tutorials from production servers.

To remove the examples that are installed with Macromedia Spectra 1.0, remove the following directories:

web_root\ibuild
web_root\allaire\spectra\restorenet
web_root\allaire\spectra\docs

In addition, access to theweb_root\allaire\spectra\docs directory should be secured with operating system and Web server security on developer workstations.

Also, per ASB00-02, there is a denial of service issue associated with a configuration directory:

web_root/allaire/spectra/install/

You should also remove this directory from production servers.

Macromedia Spectra 1.0.1

Macromedia Spectra 1.0.1 administrators should verify that the recommendations for Macromedia Spectra 1.0 are applied to any Macromedia Spectra 1.0.1 servers, especially if the server was upgraded from Macromedia Spectra 1.0.

Administrators should also verify that the Macromedia Spectra 1.0.1 workaround from ASB00-23 is applied.

To apply the workaround, remove the following directory from the Macromedia Spectra 1.0.1 install: