# http-verb-tampering

HTTP verb Tampering attack exploits web servers that accept many HTTP verbs and methods. This can be exploited by sending malicious requests using unexpected methods, which may lead to bypass authorization mechanism and its security controls against.

Misconfigurations on the back-end server or the web application leads to HTTP verb tampering attack.

Two methods, GET and POST are generally used in a web application if back-end server and web application are configured only to accept GET and POST requests. In that case, sending a different request will cause a web server error page to be displayed or leads to information disclosure.

HTTP Parameters:

| Verb    | Description                                                                                       |
| ------- | ------------------------------------------------------------------------------------------------- |
| HEAD    | Identical to a GET request, but its response only contains the headers, without the response body |
| PUT     | Writes the request payload to the specified location                                              |
| DELETE  | Deletes the resource at the specified location                                                    |
| OPTIONS | Shows different options accepted by a web server, like accepted HTTP verbs                        |
| PATCH   | Apply partial modifications to the resource at the specified location                             |
| Connect | It establishes a tunnel to the server identified by the target resource                           |
| Trace   | It performs a message loop-back test along the path to the target resource                        |

## Insecure Configurations

#### Insecure config

Any system admin may use the following insecure configurations.

```
<Limit GET POST>
	Require valid-user
</Limit>
```

#### Insecure coding

```
$pattern = "/^[A-Za-z\s]+$/";
		
if(preg_match($pattern, $_GET["code"])) {
	$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
	...SNIP...
}
```

> In this case, sanitization filter is only been tested on GET parameter. An attacker may use a POST request to perform SQL injection because GET parameter would be empty (will not include any bad characters). The request would pass the security filter.

## Basic authentication Bypass

* We just need to try alternate HTTP methods to see show they are handled by the web server.

```
GET
POST
OPTIONS (use it to see which HTTP methods are accepted by the server)
PUT
DELETE
HEAD
TRACK
TRACE
CONNECT
PATCH
```

## Security filters Bypass

* The other and more common type of HTTP Verb Tampering vulnerability is caused by Insecure Coding errors made during the development of the web application, which lead to web application not covering all HTTP methods in certain functionalities.
* This is commonly found in security filters that detect malicious requests. For example, if a security filter was being used to detect injection vulnerabilities and only checked for injections in POST parameters (e.g. `$_POST['parameter'])`, it may be possible to bypass it by simply changing the request method to GET.

> Change the HTTP request method from the Burpsuite options menu by right-click.

## HTTP verb Tampering prevention

**Insecure configurations**

* Do not limit the authorization configuration to a specific HTTP verb.

**Insecure coding**

* To identify this vulnerability in the code, we need to find inconsistencies in the use of HTTP parameters across functions.

```
if (isset($_REQUEST['filename'])) {
	if (!preg_match('/[^A-Za-z0-9. _-]/', $_POST['filename'])) {
		system("touch " . $_REQUEST['filename']);
	} else {
		echo "Malicious Request Denied!";
	}
}
```

**Combine two or more technique**

```
TRACK /upload.php/ HTTP/1.1
Host: dev.inlanefreight.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Priority: u=0, i
Via: 1.1 dev.inlanefreight.local
X-Custom-IP-Authorization: 127.0.0.1
Connection: close
```

## 403 Bypass

[Learn more about it](https://blog.vidocsecurity.com/blog/401-and-403-bypass-how-to-do-it-right/)

**Headers:**

```
X-Forwarded-For
X-Forward-For
X-Forwarded-Host
X-Forwarded-Proto
Forwarded
Via
X-Real-IP
X-Remote-IP
X-Remote-Addr
X-Trusted-IP
X-Requested-By
X-Requested-For
X-Forwarded-Server
X-Custom-IP-Authorization
```

**Values:**

```
10.0.0.0
10.0.0.1
127.0.0.1
127.0.0.1:443
127.0.0.1:80
localhost
172.16.0.0
```