How to exploit HTTP Methods

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.


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.


Using the PUT method, you can upload any file on the server. This can be used to perform Cross Site Scripting (XSS). Today, I have performed this attack, so replying here with my experience. How you do this is explained below.

PUT /XSS.html HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.myblog.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182
(Input your XSS script here)

The server responds back with a 201 status code which says “file was created successfully”.

HTTP/1.1 201 Created
Date: Mon, 05 May 2014 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

Now we can try to access this uploaded XSS.html file in browser. As soon as you access this page, you get an XSS pop-up.

Likewise, this can be further exploited to perform Command Injection as well, though I haven't tried this yet. If application uses XML, then XML External Entity attack can also be performed. Havent done this too yet. Directory Traversal attack may be possible, too.

Tags:

Http

Web Application

Appsec

Attacks

Recent Posts