Blogging Techstacks

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)

trap{
Write-Host $_
#clean up the current request
$request.Abort()
#an error occurred. ignore it and continue to returning false.
continue
}

$request = [System.Net.WebRequest]::Create($url)
$request.Method = $method
$request.TimeOut = 5000
if ($request.GetResponse().StatusCode -eq "OK")
{
#clean up the current request
$request.GetResponse().Close()
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.

PowerShell Script to Test for TRACE method

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

UPDATE: This script has been slightly updated to allow you to test for other methods. See here for more details. 

In a previous post, I described an iRule for BigIP that will allow you to disable the TRACE method, which you can attach to your VIPs instead of manually checking your hundreds of servers to verify whether the TRACE method is enabled or disabled.  Most modern web servers, including Apache, IIS 6+, tomcat 5.5+) ship with the TRACE method disabled, however.

I described in another post a theory as to why the PCI scanner keeps flagging your sites as being vulnerable because it is not actually running a TRACE but is executing an OPTIONS method instead and scraping the Response Headers.  You could ask your third-party auditer yourself but they may not know or won't tell you.  This makes verification that the vulnerability has really been remedied up to you.

The following PowerShell script, which was only slightly adapted from the very good book Pro Windows PowerShell published by Apress (so author Hristo Deshev deserves all the credit) will allow you to test to see what happens when executing a TRACE method against your newly irule-protected sites. Executing "./testSiteForTrace.ps1 <url>" will return True if TRACE requests work and False if they fail.  It also has the added bonus of posting the message received from the server when a False is generated.  I do not yet understand why the script returns false when a trailing slash is added to the URL though.  For example, testSiteForTrace.ps1 http://www.apache.org returns True but testSiteForTrace.ps1 http://www.apache.org/returns False. If anyone knows, let me know please.

param ($url)
trap{
Write-Host $_

$request.Abort()

continue
}

$request = [System.Net.WebRequest]::Create($url)
$request.Method = "TRACE"
$request.TimeOut = 5000
if ($request.GetResponse().StatusCode -eq "200"){

$request.GetResponse().Close()
return $true
}

return $false

Running this against one of my sites, I get the following message:
The underlying connection was closed: An unexpected error occurred on a receive. Which is perfect!