Add TraceEnable

[mathiasbynens]

This is what the default /etc/apache2/conf.d/security file says:

#
# Allow TRACE method
#
# Set to "extended" to also reflect the request body (only for testing and
# diagnostic purposes).
#
# Set to one of:  On | Off | extended
#
TraceEnable Off
#TraceEnable On

https://httpd.apache.org/docs/2.2/mod/core.html#traceenable

It wouldn’t hurt to add TraceEnable off to the config (overriding the default value on).

[efes0]

last i heard to be pci compliant you need to set TraceEnable off

for some reason we also had to set the following

RewriteCond %{REQUEST_METHOD} ^TRACE
RewriteRule .* <96> [F]

[AD7six]

👍

[alrra]

From https://httpd.apache.org/docs/current/mod/core.html#TraceEnable

Despite claims to the contrary, TRACE is not a security vulnerability and there is no viable reason for it to be disabled. Doing so necessarily makes your server non-compliant.

@mathiasbynens Can you provide more details on why this should be done? Thanks!

[efes0]

this is a bit old but if it still holds true...

https://bugzilla.redhat.com/show_bug.cgi?id=463940

http://www.apacheweek.com/issues/03-01-24#news

[mathiasbynens]

As the docs say:

The default TraceEnable on permits TRACE requests per RFC 2616, which disallows any request body to accompany the request. TraceEnable off causes the core server and mod_proxy to return a 405 (Method not allowed) error to the client.

There is no reason to allow TRACE HTTP requests on a production website.

From https://httpd.apache.org/docs/current/mod/core.html#TraceEnable

Despite claims to the contrary, TRACE is not a security vulnerability and there is no viable reason for it to be disabled. Doing so necessarily makes your server non-compliant.

Note that per RFC 2616, support for HTTP TRACE is OPTIONAL: http://tools.ietf.org/html/rfc2616#section-5.1.1 So it is perfectly compliant to disable it.

[alrra]

@efes0, @mathiasbynens Thanks for your comments!

[ryran]

For the record (and for future search-engine users stumbling across this), the original HTTP/1.1 RFC2616 mentioned above by @mathiasbynens was superceded in 2014 by a collection of updated HTTP/1.1 RFCs.

That said, his point about TRACE being optional still holds of course. Here's the updated link and verbiage -- i.e., from RFC7231's Overview of Methods:

This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table.
...
All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL.

[XhmikosR]

Can someone make a PR?

[Malvoz]

The OWASP documentation on:

Cross-Site Tracing (XST) suggests that:

Modern browsers now prevent TRACE requests being made via JavaScript, however, other ways of sending TRACE requests with browsers have been discovered, such as using Java.

In Test HTTP methods:

HTTP offers a number of methods that can be used to perform actions on the web server. Many of theses methods are designed to aid developers in deploying and testing HTTP applications. These HTTP methods can be used for nefarious purposes if the web server is misconfigured.

... methods that should be disabled are the following:

PUT: ... An attacker can exploit it by uploading malicious files.

DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a DoS attack.

CONNECT: This method could allow a client to use the web server as a proxy.

TRACE: ... This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing.

And in Testing for HTTP Verb Tampering:

As long as the web application being tested does not specifically call for any non-standard HTTP methods, testing for HTTP verb tampering is quite simple. If the server accepts a request other than GET or POST, the test fails. The solutions is to disable all non GET or POST functionality within the web application server, or in a web application firewall.

This issue is focusing solely on TRACE, however if methods other than GET and POST are deemed safe to disallow entirely: Just send a 405 Method Not Allowed for everything else?

E.g:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST) [NC]
RewriteRule .* - [R=405,L]