4

I am making a web-based application and I disabled some of the HTTP methods which are not necessary for the website (specifically, OPTIONS, HEAD and TRACE).

I put this in the httpd.conf of my xampp to test whether this works:

RewriteEngine On
RewriteCond %{REQUEST_METHOD} !^(GET|POST|PUT)
RewriteRule .* - [R=405,L]

How would I know whether they really are deactivated? How can I test that this setting is working properly? I am new to server-side administration.

6

@Owen nailed it, but just to show an example of doing it yourself:

$ telnet localhost 80
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
TRACE / HTTP/1.0

HTTP/1.1 405 Method Not Allowed
Date: Tue, 19 Nov 2013 12:11:40 GMT
Server: Apache/2.2.22 (Linux/SUSE)
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=iso-8859-1
Content-Language: en
Expires: Tue, 19 Nov 2013 12:11:40 GMT

The TRACE / HTTP/1.0 is what you type, followed by two newlines. The first line of the response (405 Method Not Allowed) tells you that the web server doesn't accept TRACE.

Knowing how to form a request of the different methods can be difficult if you don't already know HTTP; the OWASP project has some examples on how to Test HTTP Methods which can help you.

4

You can use a tool like netcat or telnet to do this from command line.

If you prefer to avoid the command line, or new commands you're not familiar with then tools like POSTMAN will allow you to form custom HTTP commands in a browser, and view the result.

Also worth noting that commands can mostly be disabled with commands in the httpd.conf, and that this might be preferable. For instance TraceEnable Off will disable the TRACE command.

3

This step in the OWASP Testing Guide (v4) shows how to do this in detail using the original netcat:

$ nc www.victim.com 80 
OPTIONS / HTTP/1.1
Host: www.victim.com

HTTP/1.1 200 OK
[...]
Allow: GET,HEAD,POST,OPTIONS,TRACE

This relies on the server supporting OPTIONS, and reporting back the supported list — this is not always the case (as you're about to find out), but should work fine with an unhardened Apache. One could incorrectly "harden" a web server by removing the OPTIONS method and nothing else, and most scanners won't notice the problem.

You could also use GNU netcat (old and unmaintained now), or better still nmap's ncat which supports SSL/TLS: ncat --ssl www.victim.com 443 .

It's also possible to use the nmap http-methods script, but this is really only useful for testing beforehand (since it refuses to proceed if OPTIONS does not provide a list of methods):

nmap -vvv --script=http-methods.nse \
     --script-args http-methods.retest=1 -p 80,443 www.victim.com

Since you are using Apache httpd (included with XAMPP), as an alternative to mod_rewrite you can also use the core LimitExcept directive to provide similar filtering of request methods. Note that disabling TRACE may make the HTTP server non-compliant with the specification (though you should be OK if you return either "405 Method Not Allowed" as you are doing, or "501 Not Implemented"). GET and HEAD are the only two mandatory request methods for a "general-purpose" server.

If you have perl with lwp, and the GET command is installed you can enumerate these yourself without relying on OPTIONS at all:

for mm in GET HEAD PUT POST DELETE OPTIONS PATCH TRACK TRACE PATCH; do
  printf "\n\n$mm\n======\n"
  GET -USf -m $mm http://www.victim.com/does/not/exist/OTQ4NzEzMzgxNTg3NzE3NTg1MzA2MzkK
done

You'll need to inspect the HTTP code for each, 405 and 406 are indicators of a method not being permitted. The above method list is incomplete, WebDAV adds many more methods, and see also the IANA HTTP method registry (there are proprietary ones too, there was at least one X-MS- prefixed method in old versions of MS-Exchange).

Finally, there's a useful online tool which remotely scans your web site, and produces a detailed report here: http://www.askapache.com/online-tools/request-method-scanner/ . This too only uses the OPTIONS method.

  • I love the idea of the askapache tool but it doesn't seem to work. It doesn't show anything of the server response, and it thinks my web server doesn't 200 a GET (which is what it does in manual testing). – gowenfawr Nov 19 '13 at 12:37
  • I got a detailed 28 item report with my most recent scan... Try scanning scanme.nmap.org -- that definitely works. Likely causes of problems: firewall, DNS or mismatched virtualhost names. Scans should originate from 198.101.128.0/24. – mr.spuratic Nov 19 '13 at 13:22
  • Ah - it doesn't like using the IP instead of the name. – gowenfawr Nov 19 '13 at 14:40
2

Whilst this question has many valid and good answers, another approach you could take is possibly get the LiveHTTPHeaders addon for firefox and then replay your requests to the website, with the new HTTP verb.

This technique is often referred to as HTTP verb tampering, and can be quite useful when pentesting.

Here is a quick python script I wrote, which loops over a list of HTTP verbs, obtains a response and prints them out

1

Another way to do this is to use the popular HTTPie client, aka http.

$ http TRACE https://127.0.0.1 fooHeader:barValue
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 257
Content-Type: message/http
Date: Mon, 20 Nov 2017 19:51:56 GMT
Server: Apache/2.4.27 (Amazon) mod_wsgi/3.5 Python/2.7.12

TRACE / HTTP/1.1
host: 127.0.0.1
Accept: */*
Accept-Encoding: gzip, deflate
fooHeader: barValue
User-Agent: HTTPie/1.0.0-dev
Connection: keep-alive

Notice how it responds, and how it echoes back the custom header too.

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.