PRIMARY CATEGORY → WEB ATTACKS

Theory

HTTP Verbs

Aside from GET and POST

VERBDESCRIPTION
HEADIdentical to a GET request, but its response only contains de headers section
PUTWrites the request payload to the specified location
DELETEDeletes the resource at the specified location
OPTIONSShows different options accepted by the web server, such accepted HTTP verbs
PATCHApply 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