Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Many security scanners like nikto, nessus, nmap, and w3af sometimes show that certain HTTP Methods like HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, etc are vulnerable to attack.

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.

share|improve this question
    
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. –  Digital Fire Oct 10 '12 at 20:31
1  
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? –  Stephen Touset Oct 10 '12 at 20:33
    
The O'Reilly book on HTTP would be a good place to start. –  james.garriss Mar 21 '13 at 15:53
    
Only GET and POST can be called by most web browsers, whereas the others can be called by any other HTTP client. Technically, could not do an XSS attack against a PUT method in the browser, because browsers don't PUT. –  Neil McGuigan Nov 19 '13 at 19:36

2 Answers 2

up vote 10 down vote accepted

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.

  • 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.

share|improve this answer
1  
OPTIONS is heavily used nowadays for REST APIs –  Neil McGuigan Nov 19 '13 at 19:34
    
OPTIONS is heavily used in new HTML5 security model –  dungeon Hunter Apr 1 at 8:31

The primary warning about TRACE is that it is designed to pick apart the routing of an HTTP request similar to how traceroute is meant to pick apart the routing of a packet. The key difference is that the TRACE command involves operations on the backend and disclosure of what has been received. This could be an issue if your front-end provides API keys or the something similar to your backend.

Check out RFC 2616 for more info on TRACE as well as explanations about other headers.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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