On Mon, Jun 13, 2011 at 11:54:05PM -0700, Paulino Calderon wrote:
Here is my new version of http-trace. This new version was created
to fix some issues that were discussed a while ago:
Thanks Paulino! This looks good and works well in my testing. I
receive output like:
Nmap scan report for mit.edu (18.104.22.168)
Host is up (0.10s latency).
rDNS record for 22.214.171.124: WEB.MIT.EDU
PORT STATE SERVICE
80/tcp open http
| http-trace: TRACE is enabled
| Date: Mon, 27 Jun 2011 18:42:27 GMT
| Server: Apache/1.3.41 (Unix) mod_ssl/2.8.31 OpenSSL/0.9.8j
| Connection: close
| Transfer-Encoding: chunked
I have a few suggestions:
o It should probably be added to the "vuln" category. Even though it
isn't a directly exploitable vulnerability in itself, I think people
who do "--script vuln" will want to know about it. Keeping it in
"discovery" seems fine too.
o The headers in the example above don't really give us anything we
couldn't get from http-headers. The question is whether there are
cases where we do get extra, valuable information? I'd suggest:
1) If the trace-specific header information is unlikely to be useful
beyond what we could get with http-headers, it should be removed
or made to require debug level of at least one or something.
2) If the header information is likely to be useful in some cases,
maybe we can build a list of "basic" headers to ignore, like the
five above. That way the user only sees headers which are
unusual and more likely to be worth noting.
Once you deal with these issues, please do check the script in
(replacing current http-trace).
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/