How to exploit HTTP Methods
What do these headers do and how can they be exploited?
I'm looking something more creative than common exploits like POST or GET injections (e.g., changed fields). It would help me to understand if your answer showed me a brief example of the normal usage of the header as compared to an exploit technique of a header.
Also, the question came up because on one of my servers. I got a warning that my TRACE method was vulnerable. Problem is, I don't know what trace does or how to exploit it.
You seem to have some basic confusion about HTTP in general. HTTP methods are not headers. Perhaps reading the relevant part of the RFC is in order?
Some of these methods are typically dangerous to expose, and some are just extraneous in a production environment, which could be considered extra attack surface. Still, worth shutting those off too, since you probably wont need them:
- HEAD, GET, POST, CONNECT - these are completely safe, at least as far as the HTTP Method itself. Of course, the request itself may have malicious parameters, but that is seperate from the Method... these are typically (note exception below) the only ones that should be enabled.
PUT, DELETE - as mentioned by @Justin, these methods were originally intended as file management operations.
Some web servers still support these in their original format. That is, you can change or delete files from the server's file system, arbitrarily. Obviously, if these are enabled, it opens you to some dangerous attacks.
File access permissions should be very strictly limited, if you absolutely MUST have these methods enabled. But you shouldn't, anyway - nowadays, there are simple scripts you can use (if this is a static website - if it's an actual application, just code it yourself) to support this feature if you need it.
NOTE: One valid scenario to enable these methods (PUT and DELETE) is if you are developing a strictly RESTful API or service; however, in this case the method would be handled by your application code, and not the web server.
OPTIONS - this is a diagnostic method, which returns a message useful mainly for debugging and the like. This message basically reports, surprisingly, which HTTP Methods are active on the webserver. In reality, this is rarely used nowadays for legitimate purposes, but it does grant a potential attacker a little bit of help: it can be considered a shortcut to find another hole.
Now, this by itself is not really a vulnerability; but since there is no real use for it, it just affects your attack surface, and ideally should be disabled.
NOTE: Despite the above, OPTIONS method IS used for several legitimate purposes nowadays, for example some REST APIs require an OPTIONS request, CORS requires pre-flight requests, and so on. So there definitely are scenarios wherein OPTIONS should be enabled, but the default should still be "disabled unless required".
TRACE - this is the surprising one... Again, a diagnostic method (as @Jeff mentioned), that returns in the response body, the entire HTTP Request. This includes the request body, but also the request headers, including e.g. cookies, authorization headers, and more.
Not too surprising, this can be substantially misused, such as the classic Cross-Site Tracing (XST) attack, wherein an XSS vector can be utilized to retrieve HttpOnly cookies, authorization headers, and such. This should definitely be disabled.
One other set of Methods bears mentioning: ALL OTHERS. For some webservers, in order to enable/disable/restrict certain HTTP Methods, you explicitly set them one way or another in the configuration file. However, if no default is set, it can be possible to "inject" additional methods, bypassing certain access controls that the web server may have implemented (poorly). See for example some more info on OWASP.
@AviD You added a note after the options section, but you left this bit in " In reality, this is rarely used nowadays for legitimate purposes." This conflicts with the note you added
@AviD the CONNECT method can be used to exploit the Webserver as a proxy, so i wouln't call that completely safe, since that can be a serious misuse with consequences for the hoster.
@Gewure can you explain? Of course there can be additional vulnerabilities exploitable via a specific method, but that doesn't make the availability of the method an issue...?
@AviD yes sure; i came across this recently doing some testing of our embedded webserver. I have to say i have no idea, how to exploit this, but OWASP lists it as risk and suggests to shut down the method, if not needed: https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)