PRIMARY CATEGORY → WEB ATTACKS
Theory
HTTP Verbs
Aside from GET and POST
| VERB | DESCRIPTION |
|---|---|
| HEAD | Identical to a GET request, but its response only contains de headers section |
| PUT | Writes the request payload to the specified location |
| DELETE | Deletes the resource at the specified location |
| OPTIONS | Shows different options accepted by the web server, such accepted HTTP verbs |
| PATCH | Apply partial modification to the resource at the specified location |
This vulnerability may be caused by either Insecure Web Server Configuration or Insecure Web Application Coding
Insecure Configuration
e.g. via .HTACCESS
A sysadmin may add the following snippet to an .htaccess file to require authentication on a particular web page or directory
Validation Code
<Limit GET POST>
Require valid-user
</Limit>The caveat of this approach is the absence of the remaining HTTP verbs, which could cause that an adversary uses a different HTTP method to bypass this authentication measure
Insecure Coding
it may occurs if a web developer secures the code to prevent a given vulnerability, such as SQLi, by applying some input validation while not covering all HTTP methods with the filter in question
Validation Code
$pattern = "/^[A-Za-z\s]+$/";
if(preg_match($pattern, $_GET["code"])) {
$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
...SNIP...
}The validation filter is only being tested for HTTP GET parameters. However, we can see that the $_REQUEST['code'] parameter is used within the query. The former supports both POST and GET parameters
Therefore, if an operator sends an HTTP POST request contaning the code parameter, there will be no validation as it only checks for GET parameters
Bypassing Basic Authentication
Insecure Web Server Configuration
This security measure is related to the Web Server Configuration
Suppose we are facing a web application for which a basic HTTP Authentication is required when trying to perform a privileged action on it, such as request a PHP script or access a certain directory
In this case, an operator could send the same request but using a different HTTP method
In order to know which HTTP methods the given web server supports, we can send the following request by leveraging the OPTIONS method
curl --silent --location --request OPTIONS --head '<URL>'Then, as stated, we can send the same request but modifying the HTTP verb to something other than POST or GET, which we know that are being protected by the HTTP basic authentication
To do so, simply intercept the original GET or POST request using an HTTP proxy, such as Burp, and change the given method to a different and allowed one, such as PUT or HEAD
Bypassing Security Filters
Insecure Web Application Coding
The other and most common type of HTTP Verb Tampering vulnerability is caused by the insecure code on the given web application
Imagine we are facing a file manager web application that may uses system functions, such as system() or shell_exec(), to carry out any file-related operation, which is a poor security practice
However, it filters out any special characters included within the request parameters, preventing a potential command injection
The problem is that is only taking into account GET parameters, which makes the feature vulnerable to HTTP Verb Tampering, as an operator could send a POST request and inject shell special chars to carry out a command injection attack
Similarly to the previous case, we can use an HTTP proxy to intercept the given HTTP request and change to another method before sending it