# HTTP TRACE method

## Disable HTTP TRACE in 8.0 and later

### Default setting

The HTTP TRACE method is disabled by default in IBM HTTP Server 8.0 and
later. No action is required in these releases.

## Disable HTTP Trace in 7.0 and earlier

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

The TRACE capability could be used by vulnerable or malicious
applications to trick a web browser into issuing a TRACE request against
an arbitrary site and then send the response to the TRACE to a third
party using web browser features.

### Making the required configuration changes

In IBM HTTP Server 7.0 and later, the "TraceEnable" directive is
provided to disable the TRACE HTTP method. See the Apache HTTP Server
documentation
[here](http://publib.boulder.ibm.com/httpserv/manual70/mod/core.html#traceenable)
for more info. Unlike the mod\_rewrite method described below, this
directive *only* controls TRACE responses generated internally by
Apache.

After WebServer Plugin APAR PM22860 (6.1.0.35, 7.0.0.15, 8.0.0.0), the
core `TraceEnable` directive is also honored by requests handled by the
WebServer plugin.

IHS can be configured to disable normal TRACE request processing so that
the request fails with 403 (forbidden) and 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
[mod\_rewrite](http://publib.boulder.ibm.com/httpserv/manual60/mod/mod_rewrite.html)
directives to the web server configuration file, at main scope as well
as in every `<VirtualHost >` container. If you use the IHS
Administration Server, and it listens on a client accessible interface,
the directives should be added there as well if the listening port can't
be restricted to an internally facing interface.

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:

<table>
<tbody>
<tr class="odd">
<td align="left">IBM HTTP Server 1.3 customers: Even if mod_rewrite is already enabled, check the instructions for allowing it to take precedence over the WebSphere plug-in.</td>
</tr>
</tbody>
</table>

  - [How to enable mod\_rewrite](enable_mod_rewrite.html)

## Verifying that TRACE is disabled

After TRACE has been disabled according to the instructions above, a
TRACE request will be responded to with either a HTTP status code of 403
or 405.

  - IBM HTTP Server 7.0 and later: The server will respond with a "405:
    Method Not Allowed" HTTP status code
  - IBM HTTP Server 6.1 and earlier: The server will respond with a
    "403: Forbidden" HTTP status
code

### Using telnet to verify the configuration for a non-SSL web server port

The `telnet` command provided with most operating systems can be used to
verify that the configuration changes to disable TRACE have been made.
Note that telnet can only be used to test non-SSL ports, since it does
not have the capability to perform the SSL handshake or to encrypt the
data.

    $ 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 or 405..

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.

### Using the `openssl` command to verify the configuration for an SSL-enabled web server port

`openssl` is a command-line program which is part of the OpenSSL
toolkit. It is not distributed with IBM HTTP Server. It is a typical
component of a Linux system, and it is available for other platforms. A
package for AIX can be obtained from the [AIX Toolbox for Linux
Applications
site](http://www-1.ibm.com/servers/aix/products/aixos/linux/download.html)
(follow the link labeled *AIX Toolbox Cryptographic Content*) and is
already installed on many AIX systems. Refer to
[http://www.openssl.org](http://www.openssl.org/) for availability on
other operating systems.

There may be other tools available for testing the TRACE configuration
on an SSL port. `openssl` is used as an example here because it is
freely available.

Unlike telnet, the `openssl` command can be used to perform the SSL
handshake with the web server, at which point the TRACE command can be
entered. Here is an example:

    $ /usr/linux/bin/openssl s_client -connect 127.0.0.1:8444
    CONNECTED(00000003)
    depth=0
    /C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
    verify error:num=18:self signed certificate
    verify return:1
    depth=0
    /C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
    verify return:1
    ---
    Certificate chain
     0 s:/C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
       i:/C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    MIICUzCCAbygAwIBAgIEQFxItjANBgkqhkiG9w0BAQQFADBuMQswCQYDVQQGEwJV
    UzEOMAwGA1UEERMFMjc2MDcxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxlaWdo
    MQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBG0weGExEzARBgNVBAMTClRSQVdJQ0st
    VFAwHhcNMDQwMzE5MTMzNTUwWhcNMDYxMjE1MTMzNTUwWjBuMQswCQYDVQQGEwJV
    UzEOMAwGA1UEERMFMjc2MDcxCzAJBgNVBAgTAk5DMRAwDgYDVQQHEwdSYWxlaWdo
    MQwwCgYDVQQKEwNJQk0xDTALBgNVBAsTBG0weGExEzARBgNVBAMTClRSQVdJQ0st
    VFAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL20PHlKPcWPANcH8cQ5j2Ev
    40p8HZhY4lQMY7rYebDlglJikMCLBePMkkMsWOAz+Wwk/jsxsw7XLyC+qPdoDZbc
    ggsZUHNwzn8/sJh3WSbKJwkSxC4hBHmO0IweDOp/LtIWjTLEeVqWDUUFoA+xMvMq
    GAf48YVlKynAI6dqnCgbAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAV+c9cSYaZCoU
    MM6GVw9sro2uWAEqc+D+iqTPtIn76P8UZOSZZEfMXNXHc1lR8iytVcFf7uv8Yob2
    2332citn82TU7PF9pAG8jOQfhtQgoLjgAYg8UNmQscJLkjeJDU0LeV7u7Czo/whp
    4l1bQA/0aqkrIl5UrTDoxqOBUPbx93c=
    -----END CERTIFICATE-----
    subject=/C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
    issuer=/C=US/2.5.4.17=27607/ST=NC/L=Raleigh/O=IBM/OU=m0xa/CN=TRAWICK-TP
    ---
    No client certificate CA names sent
    ---
    SSL handshake has read 739 bytes and written 310 bytes
    ---
    New, TLSv1/SSLv3, Cipher is RC4-SHA
    Server public key is 1024 bit
    SSL-Session:
        Protocol  : TLSv1
        Cipher    : RC4-SHA
        Session-ID:
        0000643E040608CBB4770730058AD640E7D7DBF9585858584270B25900000001
        Session-ID-ctx:
        Master-Key:
        AB897789790FFA0917335A49A6A272A162159B854EA2A9C21C1754607B412126AF09F521B0D4102387F80BC60B42FB5A
        Key-Arg   : None
        Start Time: 1114681945
        Timeout   : 300 (sec)
        Verify return code: 18 (self signed certificate)
    ---
    TRACE / HTTP/1.0         <----------- data to be entered starts here
    A: b
    C: d
    Host: foo
    
    HTTP/1.1 403 Forbidden   <----------- web server response starts here, 6.1 and earlier shown only
    Date: Thu, 28 Apr 2005 09:52:29 GMT
    Server: IBM_HTTP_Server/2.0.47.1-PK01070 Apache/2.0.47 (Unix)
    Content-Length: 306
    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>
    <p>You don't have permission to access /
    on this server.</p>
    <hr />
    <address>IBM_HTTP_Server/2.0.47.1-PK01070 Apache/2.0.47 (Unix) Server
    at foo Port 8444</address>
    </body></html>
    read:errno=0
    $

### TRACE and OPTIONS

The OPTIONS method can be used by a client to determine which methods
are allowed. Even when TRACE is disabled using the mod\_rewrite method
above, the OPTIONS response will report that TRACE is enabled. However,
TRACE will be rejected with a 403 error before it is processed, and the
potentially harmful behavior of TRACE — echoing input data to the
response — won't be allowed.

### For more information...

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

## The HTTP TRACK method

The `TRACK` method is a type of request supported by Microsoft web
servers. It is not RFC compliant and is not supported directly by IBM
HTTP Server. The method may be utilized as part of a cross-site
scripting attack. See [Vulnerability Note
VU\#288308](http://www.kb.cert.org/vuls/id/288308) for more information.

Even though IBM HTTP Server does not support the `TRACK` method
natively, it is possible for plug-in modules to provide support for it.
To disable this capability for plug-in modules, in addition to disabling
the `TRACE` method, add these two additional directives after the
existing `RewriteCond` and `RewriteRule` directives which are used to
disable `TRACE`:

    RewriteCond %{REQUEST_METHOD} ^TRACK
    RewriteRule .* - [F]

Here is a full example showing the directives to disable both `TRACE`
and `TRACK`:

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

Note that for IBM HTTP Server 7.0 and later, the only method to disable
TRACK is via mod\_rewrite. Since IHS doesn't do anything with TRACK,
there is no directive to "disable" it.