8 posts categorized "Disable TRACE"


Tomcat - Disable TRACE Method

This article has been superseded by this one. 
No further updates will be made to this article. 

I've been seeing some searches get directed to this site for folks looking for ways to disable the HTTP TRACE method on tomcat. If you are using tomcat 4.1+, 5.5+. or 6.0+, by default the TRACE method is disabled. If you are getting tagged by a PCI scanner that TRACE/TRACK is enabled, there are three possible reasons that I can think of.

The first cause is that you actually do have trace enabled. Check your server.xml and look in the HTTP connector section for an attribute labeled "allowTrace". If set to True, get rid of it or change it to False.

The second cause is that your tomcat is front-ended by an apache or IIS server that has trace enabled and you need to remediate there, not at tomcat.

The third potential cause is that your seeing a false positive. False positives usually pop up for me when using custom errors or redirects and when the scanner hits a particular page and gets redirected, the 302 is not an expected response.


Updated Powershell Script to Test For Trace

This article has been superseded by this one. 
No further updates will be made to this article.

In a previous post, I posted a basic powershell script that would test a site to see whether the TRACE method was enabled or not. I've updated that script so now you can test for other methods. Here is the updated script:

## USAGE: ./testURL.ps1 <http-method-to-test> <site-to-test-without-trailing-slash>
## Not sure why, but this script returns true if you use a URL like http://www.apache.org
## but fails if you use the correct URI syntax (http://www.apache.org/ << note trailing slash

param ($method,$url)

Write-Host $_
#clean up the current request
#an error occurred. ignore it and continue to returning false.

$request = [System.Net.WebRequest]::Create($url)
$request.Method = $method
$request.TimeOut = 5000
if ($request.GetResponse().StatusCode -eq "OK")
#clean up the current request
return $true
#should get here only if we got an error for our web request
return $false

Running the script is a matter of typing in the method you want to execute followed by the URL of the site you want to test: ".\testURLv2.ps1 %HTTPMETHOD% %URL%"

Enjoy! This script allows you to test to see if Methods like TRACK and OPTIONS work in additon to simply testing that the TRACE method works.


Apache Configuration and PCI Compliance - Configuration Change #3

Check out the new HOWTO Guides section for an up-to-date version of this post.

I have launched a new section on this site and you can find HOWTO: Disable Trace and Track in Apache HTTPD there.

In previous articles, I posted about the need to secure your Apache server using ServerTokens and setting SSLProtocol and SSLCipher directives to disable SSLv2 and null and weak ciphers. This post will concentrate on disabling certain http methods because they are enabled by default in Apache and because they will haunt you after your next quarterly pci compliance scan.

If you are running IIS6 or later, you're in luck. The TRACE method is disabled by default, although TRACK does work. This is not the case with Apache however and if you run lots of sites, your very first PCI Compliance scan will have all of your apache sites listed as vulnerable to the "HTTP TRACE/TRACK Method Support Cross-Site Tracing Vulnerability".

The one way that I know of to do away with this is with a mod_rewrite rule. There are lots of examples out there on the web for this but here's one below. You need to make sure that you are loading mod_rewrite.so in your apache configuration. Then it's just a matter of adding the following to your httpd.conf (or httpsd.conf):

RewriteEngine on
RewriteRule .* - [F]

Alternatively, if you are using a newer version of Apache, you can add the TraceEnable directive and set it to "Off".

You don't necessarily need to disable TRACK in Apache but if you're looking to cover all your bases, modify the rewrite rule as follows to disable TRACE, TRACK, and OPTIONS.

RewriteEngine on
RewriteRule .* - [F]

Why disable OPTIONS? There is no real good reason that I've been able to find. I do not know if some Approved Scanning Vendors will mark you out-of-compliance for TRACE if they simply submit an "OPTIONS *" request against your site. (If you disable TRACE and submit an OPTIONS request, TRACE still shows up as an Allowed communication method on Apache and IIS) However, I've had reports that if you make spreadsheets available and want to open them in place using Excel, disabling OPTIONS will cause problems if the resource is SSL protected. I've also experienced first hand that some versions of CICS will submit an OPTIONS request prior to submitting a POST, so if some of your mainframe customers are using an older version of CICS, disabling OPTIONS could cause them problems.