Disabling the HTTP TRACE method

The HTTP TRACE request method causes the data received by IBM HTTP Server from the client to be sent back to the client, as in the following example:

$ telnet 127.0.0.1 8080
Trying...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
Host: foo
A: b
C: d

HTTP/1.1 200 OK
Date: Mon, 04 Oct 2004 14:07:59 GMT
Server: IBM_HTTP_SERVER
Connection: close
Content-Type: message/http

TRACE / HTTP/1.0
A: b
C: d
Host: foo

Connection closed.

There have been some reports of the TRACE capability being a web server vulnerability. But the only processing done by the web server is to echo the input data back to the browser. The actual vulnerability is the capability of applications to trick a web browser into issuing a TRACE request against an arbitrary site and then sending the response to the TRACE to a third party using web browser features.

IBM HTTP Server can be configured to disable normal TRACE request processing so that any private information sent in the TRACE request does not appear in the response. The way to disable normal TRACE request processing is to add several directives to the web server configuration file, at main scope as well as in every <VirtualHost > container. Here is an example:

...
# disable TRACE in the main scope of httpd.conf
RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F] 
...
<VirtualHost www.example.com>
...
# disable TRACE in the www.example.com virtual host
RewriteEngine On 
RewriteCond %{REQUEST_METHOD} ^TRACE 
RewriteRule .* - [F] 
</VirtualHost>

mod_rewrite must be active for these directives to be accepted. If mod_rewrite is not already active in your configuration:

Enabling mod_rewrite in IBM HTTP Server 1.3.x on Windows

mod_rewrite is built into Apache.exe and does not need to be enabled explicitly. However, special configuration changes are necessary to allow mod_rewrite to take precedence over the WebSphere plug-in.

If TRACE should be disabled for the WebSphere plug-in as well, the ClearModuleList and AddModule directives must be used, as shown in the following example:

LoadModule ibm_app_server_http_module D:/WebSphere/AppServer/bin/mod_ibm_app_server_http.dll
LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll
ClearModuleList
AddModule mod_ibm_afpa.c
AddModule mod_so.c
AddModule mod_mime.c
AddModule mod_access.c
AddModule mod_auth.c
AddModule mod_negotiation.c
AddModule mod_include.c
AddModule mod_autoindex.c
AddModule mod_dir.c
AddModule mod_cgi.c
AddModule mod_userdir.c
AddModule mod_env.c
AddModule mod_log_config.c
AddModule mod_asis.c
AddModule mod_imap.c
AddModule mod_actions.c
AddModule mod_setenvif.c
AddModule mod_isapi.c
AddModule mod_app_server_http.c
AddModule mod_alias.c
AddModule mod_rewrite.c
AddModule mod_ibm_ssl.c

(The actual list of AddModule directives should match the list of modules you want to enable for your configuration.)

Because mod_rewrite.c (mod_rewrite) is added after mod_app_server_http.c (WebSphere plug-in), the mod_rewrite directives to bypass TRACE will take effect for WebSphere requests since mod_rewrite will be allowed to handle the request before the WebSphere plug-in.

Enabling mod_rewrite in IBM HTTP Server 1.3.x on other platforms

The normal way to enable mod_rewrite is to verify that the following directives are uncommented:

LoadModule rewrite_module libexec/mod_rewrite.so
...
AddModule mod_rewrite.c

If the TRACE method needs to be disabled for WebSphere requests, then mod_rewrite needs to be activated after the WebSphere plug-in in the IBM HTTP Server configuration file. This can be accomplished by making sure that the LoadModule and AddModule lines listed above are commented out, and then adding the following line to the IHS configuration file after the lines which activate the WebSphere plug-in:

LoadModule rewrite_module libexec/mod_rewrite.so

Enabling mod_rewrite in IBM HTTP Server 2.0.42 and higher on all platforms

Note: This includes IBM HTTP Server 6.0 and later releases.

verify that the following directive is uncommented:

LoadModule rewrite_module modules/mod_rewrite.so

After TRACE has been disabled in this manner, a TRACE request will be responded to in this manner:

$ telnet 127.0.0.1 8080
Trying...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0
A: b
C: d
Host: foo

HTTP/1.1 403 Forbidden
Date: Mon, 04 Oct 2004 14:23:31 GMT
Server: IBM_HTTP_SERVER
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>403 Forbidden</TITLE>
</HEAD><BODY>
<H1>Forbidden</H1>
You don't have permission to access /
on this server.<P>
</BODY></HTML>
Connection closed.

The information sent by the client is no longer echoed, and the request fails with HTTP status code 403.

If the response to the TRACE request continues to result in a response with status code 200, verify that the required directives were added to all <VirtualHost > containers and the main scope of the configuration file, and also verify that the web server has been restarted to activate the updated configuration.

More background information on the concerns with TRACE is provided at http://www.apacheweek.com/issues/03-01-24#news.