# Insecure Config
- HTTP Verb Tampering vulnerabilities can occur in most modern web servers, including `Apache`, `Tomcat`, and `ASP.NET`
- Usually happens when we limit a page's authorization to a particular set of HTTP verbs/methods, which leaves the other remaining methods unprotected
## Apache
- Example of a vulnerable config for an Apache web server, which is located in the site configuration file (e.g. `000-default.conf`), or in a `.htaccess` web page configuration file
- Because the `Require valid-user` setting will only apply to `GET` requests due to `<LIMIT GET>`, this leaves the page accessible through `POST` requests
```xml
<Directory "/var/www/html/admin">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile /etc/apache2/.htpasswd
<Limit GET>
Require valid-user
</Limit>
</Directory>
```
## Tomcat
- The following example shows the same vulnerability for a `Tomcat` web server configuration, which can be found in the `web.xml` file for a certain Java web application
- Again, the authorization is being limited only to the `GET` method with `http-method`, which leaves the page accessible through other HTTP methods
```xml
<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
```
## ASP
- The following is an example for an `ASP.NET` configuration found in the `web.config` file of a web application
- Once again the following is an example for an `ASP.NET` configuration found in the `web.config` file of a web application
```xml
<system.web>
<authorization>
<allow verbs="GET" roles="admin">
<deny verbs="GET" users="*">
</deny>
</allow>
</authorization>
</system.web>
```
# Insecure Coding
- While identifying and patching insecure web server configs is easy, doing the same for insecure code is more challenging
- For example consider the below php code for the file manager web app
```php
if (isset($_REQUEST['filename'])) {
if (!preg_match('/[^A-Za-z0-9. _-]/', $_POST['filename'])) {
system("touch " . $_REQUEST['filename']);
} else {
echo "Malicious Request Denied!";
}
}
```
- Above we see that the `preg_match` filter only checks for special characters in `POST` parameters with `$_POST['filename']`and the `system` command uses the `$_REQUEST['filename']` variable, which covers both `GET` and `POST` parameters
- This is a major problem because a malicious GET parameter will get past the initial `preg_match`
# Reinforce Consistency
- To avoid HTTP Verb Tampering vulnerabilities in our code, we must be consistent with our use of HTTP methods and ensure that the same method is always used for any specific functionality across the web application
- Highly advised to expand the scope of testing in security filters by testing all request params
- This can be done with the following functions and variables:
|Language|Function|
|---|---|
|PHP|`$_REQUEST['param']`|
|Java|`request.getParameter('param')`|
|C#|`Request['param']`|