Disable Trace and Track for Better Security
The shared server on which I host Perishable Press was recently scanned by security software that revealed a significant security risk. Namely, the HTTP request methods TRACE and TRACK were found to be enabled on my webserver. The TRACE and TRACK protocols are HTTP methods used in the debugging of webserver connections.
Although these methods are useful for legitimate purposes, they may compromise the security of your server by enabling cross-site scripting attacks (XST). By exploiting certain browser vulnerabilities, an attacker may manipulate the TRACE and TRACK methods to intercept your visitors’ sensitive data. The solution, of course, is disable these methods on your webserver.
How to disable the TRACE and TRACK methods
To disable TRACE and TRACK HTTP methods on your Apache-powered webserver, add the following directives to either your main configuration file or root HTAccess file:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]These directives disable the TRACE and TRACK methods via the following process:
RewriteEngine on— enables Apache’s rewrite module (this directive is not required if already present in your htaccess file)RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)— targets all TRACE and TRACK request methods for the following ruleRewriteRule .* - [F]— return a403 Forbiddenerror response for all matched conditions (i.e., all TRACE and TRACK methods)
With these rules in place, your site is protected against one more potential security vulnerability :)
27 responses to “Disable Trace and Track for Better Security”
Hey Jeff,
Is the below code best practice for .htaccess files?
RewriteEngine onRewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)RewriteRule .* - [F]Regards,
– Dean (Sydney, Australia)
Hi Dean,
As far as I know.. I certainly try to post only “best-practice” code, but I have been known to make mistakes, from time to time. Is there something specific that causes you to question?
Hey, Jeff, thanks for the code. I’m running on Dreamhost, and they provide the ability to have an account-wide .htaccess file — an .htaccess file that is processed for every domain on a user’s account — and some things work in this file, others don’t.
This code at least doesn’t crash my site — some perfectly valid code, when used in the account-wide file, does crash things — but I’m not sure if it’s actually working.
Do you know of a way to test those request methods against a site?
Oh, never mind, I’m just dense. I tested it by adding in the GET method as well. It didn’t block requests, so I’ll have to do this the long way, adding to each of my domain’s .htaccess files.
Here’s a request: Work up a tutorial on how to modify one .htaccess file and have it reflected across as many other files as desired (via Shell/cron/whatever), making sure that site-specific code (such as WP’s permalink code) isn’t touched. So, for example, a “# Account-wide declarations” block could be copied to each file automatically. That sure would be handy!
How do you check whether TRACE and TRACK are enabled or disabled?
I recommend to add
DELETEto the list:RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK)@Rick: Good idea, but remember that .htaccess functions in cascading fashion, such that placing any directives in your root directory will — unless told otherwise — be applied to all subsequent subdirectories.
@duck: You could either ask your host or telnet to your domain with the following commands:
TRACE / HTTP/1.1[enter]Host: yourdomain.tld[enter][enter]
The first line of the result will be the response code.
@Thomas: Good call. I will update the article.
I know that, Jeff. What I’d like to be able to do is apply a variety of security functions to all of my domains (each reside in its own directory within my home directory), and manually updating each domain’s .htaccess to account for new security rules is tedious. Being able to update them all in one go would be awesome.
Ah, gotcha. On some server setups you can apply .htaccess directives to directories above the web root. So for example, if you have the following directory tree:
homepublic_htmldomain1domain2domain3domain4domain5You would simply create an .htaccess file in your
/home/or/public_html/directory to have it’s rules applied to all subdirectories (i.e., your different domains).Alternately, if you have access to your server configuration file, you could place your directives there and have them applied to everything in one fell swoop.
I can create such an .htaccess file — it works with the allow/deny rules and various other things, but mod_rewrite doesn’t work for it.
And unfortunately, on Dreamhost regular hosting, no access to real config files. :S
Okay, one more thing to try that may help. Many shared hosts have their accounts setup with a primary domain, which is generally the one specified during account creation. In many cases, the root folder for the primary domain is the
/public_html/(or equivalent) directory itself, such that its .htaccess file applies to all domains.I’m guessing that you may have already tried this, but if not, mod_rewrite should work in the .htaccess file of that directory.
Otherwise, a script that updates server-wide .htaccess files would be difficult to create, especially because you only want to target the .htaccess files in each root directory. This is certainly possible with even PHP or something, however it would require your .htaccess files to be writable, which may not be the best strategy.
Nah, there isn’t a primary domain. The structure of my account looks like this when I log in via FTP:
/domain.comdomain2.comdomain3.comEach individual domain’s folder is the root folder for that domain (i.e., there isn’t a child
public_html/orwww/or anything of that nature), and each domain’s folder (and all subsequent children) can have fully-functional .htaccess files.The
/directory itself, though, is a bit limited. It’s above the Web root, so mod_rewrite doesn’t seem to work — either that’s the reason, or it just isn’t enabled that high up.I do, however, maintain all of my configuration files (
wp-config.phpfiles, for example) in the/directory, so what I may end up doing is writing a security PHP script that checks user-agents, IPs, requests, and so on. Then all I’d need to do is include it at the top of thewp-config.phpfile.That method likely won’t be *as* quick as .htaccess (and definitely not as quick as the
http.conffile), but it will be slightly quicker than maintaining it all as an actual WordPress plugin as the included security file would launch almost immediately on page access.That’ll be a stop-gap. I’m going to look at how WordPress generates .htaccess rules, modifying.htaccess files in such a way as to not modify any other custom-added content… I might be able to write a PHP script that, when one, copies one .htaccess file to as many others as I want.
By default on my server, PHP can modify just about any files — I rarely have to CHMOD anything — and whether that’s a bad thing or not, I dunno. It is danged convenient for me, though. If I ever get something workable, I’ll share the code.