9

How can I identify the different HTTP methods supported by a web server, like OPTIONS, TRACE, etc.?

I have tried the nc command on Linux. But it doesn't work. It doesn't show me the HTTP methods supported, some other HTTP headers are returned along with the requested HTML page. Is there another solution?

Improve this question
1
  • 5
    It's probably worth pointing out that different methods may be supported by different resources.
    – Roger Lipscombe
    Commented Oct 13, 2014 at 19:10

4 Answers 4

Reset to default
8

Per RFC2616, the OPTIONS method should return the supported methods. Keyword is should since this isn't always the case. As the prior posts have already pointed out each method needs to be tested separately to be sure.

Improve this answer
2
  • 3
    What if the OPTIONS method is not among the supported methods?
    – Brandon
    Commented Oct 13, 2014 at 20:55
  • 3
    @Brandon: If the OPTIONS method isn't supported that means the server doesn't support enumerating available methods in the standard way. In other word, you're screwed anyway. A server that doesn't support the standard's prescribed way of doing things may still be capable of doing it through a non standard way, but a generic HTTP client wouldn't be able to venture a guess of what that way will be, since the server isn't standard compliant. You'll have to make do with poke and see.
    – Lie Ryan
    Commented Oct 14, 2014 at 9:51
8

As there are only few methods (OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE and CONNECT), you can use a script and nc to send a request to all allowed methods and parse the results:

for method in OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT ; do 
    echo -e "\n\nTrying $method\n\n" 
    echo -e "$method / HTTP/1.1\nHost: server-hostname\nConnection: close\n\n" | nc server-hostname 80 | head 
    sleep 2
done

HTTP errors 400, 403, 405 and 406 generally are the types returned when trying to use a not implemented method.

Improve this answer
7
  • 11
    Is that trying to DELETE the path /, just to find out whether it works?
    – Volker Siegel
    Commented Oct 13, 2014 at 21:08
  • 1
    Yes, that's the thing I am feared about. What if DELETE is supported? Will it delete it?
    – Anandu M Das
    Commented Oct 14, 2014 at 5:40
  • 2
    Getting an error does not mean that the method is not implemented... For example, if I get a 400 or 403 for POST, I will not think "Oh POST must not be supported", I will think "Duh, what data should I put in the HTTP content?"
    – Jean Hominal
    Commented Oct 14, 2014 at 8:17
  • 2
    When a webserver supports the DELETE method on the domain root without any form of authentication, the admin is obviously clueless. Unfortunately many lawyers, prosecutors, judges and jurys are equally clueless, so getting a subpoena for computer sabotage isn't completely implausible. Keep in mind that PUT can be equally destructive.
    – Philipp
    Commented Oct 14, 2014 at 9:11
  • 2
    Shouldn't this be checking for the error code 501 Not Implemented?
    – Ismael Miguel
    Commented Oct 14, 2014 at 9:22
5

The only way to identify the methods supported by a web server is to try each one and evaluate the response to determine if it indicates the method is supported or not. You can't simply query to ask which methods it supports; it won't give you a list.

That said, there are better tools than nc. Nmap and metasploit both support HTTP method scanning and essentially automate the work for you.

Improve this answer
2
  • 2
    No, you can simply query it, and it may give you a list.
    – user207421
    Commented Oct 13, 2014 at 22:22
  • using Nikto vulnerability scanner is another way to determine methods in place + Allowed HTTP Methods: GET, POST, OPTIONS, HEAD, TRACE
    – Hud Seidu Daannaa
    Commented Aug 13, 2018 at 11:08
2

There are circumstances where a HTTP server will return a list of supported methods for a given resource in its Allow response header, according to RFC 7231 (the new RFC for HTTP 1.1 semantics):

  • First in the response to an OPTIONS request, either on a specific resource path, or on the special * path (which would mainly describe the capabilities of the server);
  • Second, if a method which is known, but not supported by the server on a given resource is tried, the server can respond with a 405 Method Not Allowed status code; in that case, it must give the list of allowed methods in the Allow response header;
  • For any other HTTP request, the origin server is allowed to return a list of supported methods in the Allow response header;

But what if the server does not cooperate? E.g. you have tried an OPTIONS * request, various GET requests, and the server never returns a list of allowed methods in an Allow header? Or what if the server replies, but you suspect that it is lying?

Then you do not know, and you will have to live with it. What you will do will depend on your goal:

  • If you are simply trying to use the target system, you should do the cautious thing by assuming that only GET is supported, and obtain more documentation about how to use the system;
  • If you are doing penetration testing, then you can test all the known verbs, test some less known ones (such as PATCH) or even invent some of your own; more generally, part of the test would be throwing garbage at the system to see how it reacts;

However, think about why you want to know the list of supported verbs - because without additional data, knowing which verbs are used is close to useless (e.g. I know that https://accounts.google.com/AddSession accepts the POST verb - what good does simply knowing the verb do to me if I do not know what data should be in, in what format, etc.?)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .