There are several HTTP verbs (request methods) such as GET and POST. TRACK is one of these verbs which tells IIS to return the full request back to the client as part of the response. HTTP TRACK verb is Microsoft’s implementation and it is similar to TRACE verb which is RFC complaint.
Security scan tools often raise a flag if HTTP TRACK and TRACE verbs are enabled in your server because attackers can try capturing client cookies by forcing web servers to return full requests.
Here is a description from a security scan tool that marked the usage of this verb as a vulnerability:
The HTTP TRACK method is normally used to return the full HTTP request back to the requesting client for proxy-debugging purposes. An attacker can create a webpage using XMLHTTP, ActiveX, or XMLDOM to cause a client to issue a TRACK request and capture the client’s cookies. This effectively results in a Cross-Site Scripting attack.
Source
There is also a record in NIST’s Vulnerability Database about the TRACK verb.
HTTP TRACK/TRACE verbs and IIS
HTTP TRACK is disabled in IIS 6 and newer versions. However, you may see the TRACE verb enabled and it might be the reason why your security scan tool is complaining about TRACK verb.
I have tested IIS 7, 8.5, and 10 to see if TRACK and TRACE verbs are enabled or disabled by default. Here are my findings:
As you see in the table above, TRACK method is not allowed by default after IIS 7 (We know that IIS 6 also doesn’t allow it but I haven’t personally tested it). However, TRACE is allowed by default in IIS 8.5. This is the reason why the vulnerability “Microsoft IIS HTTP TRACK Method Information Disclosure” may show up in results of your security scan. Please note that security scanners sometimes point out HTTP TRACK usage but they actually test for HTTP TRACE method.
HTTP TRACE is an HTTP specification and it is understandable to allow it by default. I don’t have answer for why it wasn’t allowed in IIS 7 and then it became allowed in IIS 8.5. It is likely that there have been requests to allow this method back. In anyway, It is good to have flexibility to turn this method off by using Request Filtering (Instructions are in the next section).
Disable HTTP TRACK and TRACE
In order to disable HTTP TRACK verb, please follow the instructions below. This vulnerability might be flagged because of allowing HTTP TRACE verb as well so that It’s a good idea to disable both.
- Go to IIS Manager
- Click the website name
- Double click “Request Filtering” (If you don’t see Request Filtering icon, please install it)
- Go to “HTTP Verbs” tab
- Click “Deny Verb” from the Actions menu. Type “TRACE”. Click “OK”
- Click “Deny Verb” from the Actions menu. Type “TRACK”. Click “OK”
Do you receive HTTP 500 after the changes? Check this post out for the solution: Prevent settings to be overridden by web.config (HTTP Error 500.19)
Testing
If you want to test if this setting works, you can try to send a TRACE request to IIS via telnet. If it fails with 404 code, it means this request is blocked. Steps to test the setting:
- In your client machine, open Command Prompt
- Type
telnet <server-ip-address> 80
- Type the text below. Continue to enter characters even though the window won’t show what you are typing
TRACE / HTTP/1.1
Host: websitedomain.com
HostA: Hello
- Hit Enter twice
If it shows HTTP/1.1 404 Not Found, it means the setting is working. TRACE is disabled:
If it shows HTTP/1.1 200 OK, it means the setting is not working. TRACE is allowed:
After making changes, are you receiving HTTP 413 error? Check this post out: HTTP status 413 (Request Entity Too Large)
I can’t seem to get this to work — even after making the change, TRACE still seems to be enabled (I’ve done an IISRESET as well). Any thoughts?
Starting Nmap 7.40 ( https://nmap.org ) at 2019-09-13 12:12 Eastern Daylight Time
Nmap scan report for abc.abc.abc (x.x.x.x)
Host is up (0.00050s latency).
PORT STATE SERVICE
443/tcp open https
| http-methods:
| Supported Methods: OPTIONS TRACE GET HEAD POST
|_ Potentially risky methods: TRACE
Nmap done: 1 IP address (1 host up) scanned in 9.16 seconds