1

By using nc or curl I get HTTP status code 405 for TRACE requests, but if I scan my site with NMAP, it seems that TRACE is enabled. Could someone explain to me if TRACE is correctly disabled or not?

NC

nc hd1.aon.it 443
TRACE /js/jquery.cookie.js?param=1 HTTP/1.1
Host: hd1.aon.it
X-Wind: custom

HTTP/1.1 405 Method Not Allowed
Content-Length: 83
Content-Type: text/html
Date: Thu, 12 Jan 2017 12:59:04 GMT
Via: HTTP/1.1 sophos.http.proxy:3128
Connection: keep-alive

Error405 - Method Not Allowed

NMAP

nmap -p 443 --script http-methods hd1.aon.it

Starting Nmap 6.46 ( http://nmap.org ) at 2017-01-12 13:41 CET
Nmap scan report for hd1.aon.it (93.63.129.73)
Host is up (0.00026s latency).
rDNS record for 93.63.129.73: 93-63-129-73.ip27.fastwebnet.it
PORT    STATE SERVICE
443/tcp open  https
| http-methods: GET HEAD POST TRACE OPTIONS
| Potentially risky methods: TRACE
|_See http://nmap.org/nsedoc/scripts/http-methods.html

Nmap done: 1 IP address (1 host up) scanned in 2.19 seconds
  • in a browser open the dev debug console and check the file headers. The header might conflict with what the server is actually doing. – CaffeineAddiction Jan 12 '17 at 13:56
2

The http-methods script just issues an options requests and if this returns Allow methods than it trusts this information. Just try an OPTIONS request and you will get the following response:

> OPTIONS / HTTP/1.0

< HTTP/1.1 500 Internal Server Error
< Allow: GET, HEAD, POST, TRACE, OPTIONS
...

Thus the OPTIONS request itself reports that TRACE is supported. And actually the method is supported by the server:

> TRACE / HTTP/1.0

< HTTP/1.1 405 Method Not Allowed
< ...

This means that the server supports this method but actively refuses using it, at least with specific URLs. Not supported methods would result in a different kind of response:

> FOO / HTTP/1.0 

< HTTP/1.0 501 Not Implemented
< ...

... it seems that TRACE is enabled

nmap does not check if enabled or not, it checks if it supported (i.e. implemented and allowed according to OPTIONS) or not. Actively denying use of the method on specific resources does not mean that the option is not supported, i.e. implemented in the server and maybe available for specific resources.

  • To clarify, do you mean that "...denying use of the method... means that it is implemented but disabled"? The use of "supported" in some areas of this answer and "implemented" in other areas is clouding the answer a little bit for me. Does supported == implemented? – gowenfawr Jan 12 '17 at 14:25
  • @gowenfawr: yes, supported means implemented, i.e. that the server is able to deal with the method even it might decide to block usage of this method in specific cases. And just getting a 405 back for a specific URL does not mean that this method is unavailable on every resource. – Steffen Ullrich Jan 12 '17 at 14:31
  • I'm just suggesting that using two words for one thing might make this answer less useful for some readers with poor English or excessive Literal skills. Might be better to use the same word both places. – gowenfawr Jan 12 '17 at 14:35
  • 1
    @gowenfawr: I've updated the answer to make it more clear. – Steffen Ullrich Jan 12 '17 at 16:05
  • 1
    Check out the documentation for http-methods. If you add --script-args http-methods.retest it will test and verify the results of the OPTIONS request. This is not default behavior because retesting something like DELETE could be harmful to the target. – bonsaiviking Jan 12 '17 at 16:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.