☑️HTTP Verb Tampering
Introduction
Every web request starts with a verb (e.g. GET, POST). Lets say the server is configured to only handle GET and POST. But if the use of other verbs are not properly restricted at either the web server or the web application, it can be exploited.
HTTP has 9 different verbs that can be accepted as HTTP methods by web servers. Other than GET and POST, the following are some of the commonly used HTTP verbs:
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
Insecure Configuration
Here is an example of an insecure configuration. Suppose that the admin wanted the web server to require authorization to perform GET and POST requests.
<Limit GET POST>
Require valid-user
</Limit>even though the configuration specifies both GET and POST requests for the authentication method, an attacker may still use a different HTTP method (like HEAD) to bypass this authentication mechanism altogether. This eventually leads to an authentication bypass and allows attackers to access web pages and domains they should not have access to.
Insecure Coding
Insecure coding practices cause the other type of HTTP Verb Tampering vulnerabilities (though some may not consider this Verb Tampering). This can occur when a web developer applies specific filters to mitigate particular vulnerabilities while not covering all HTTP methods with that filter. For example, if a web page was found to be vulnerable to a SQL Injection vulnerability, and the back-end developer mitigated the SQL Injection vulnerability by the following applying input sanitization filters:
$pattern = "/^[A-Za-z\s]+$/";
if(preg_match($pattern, $_GET["code"])) {
$query = "Select * from ports where port_code like '%" . $_REQUEST["code"] . "%'";
...SNIP...
}We can see that the sanitization filter is only being tested on the GET parameter. If the GET requests do not contain any bad characters, then the query would be executed. However, when the query is executed, the $_REQUEST["code"] parameters are being used, which may also contain POST parameters, leading to an inconsistency in the use of HTTP Verbs. In this case, an attacker may use a POST request to perform SQL injection, in which case the GET parameters would be empty (will not include any bad characters). The request would pass the security filter, which would make the function still vulnerable to SQL Injection.
While both of the above vulnerabilities are found in public, the second one is much more common, as it is due to mistakes made in coding, while the first is usually avoided by secure web server configurations, as documentation often cautions against it.
Bypassing Basic Authentication
Exploiting HTTP Verb Tampering vulnerabilities is usually a relatively straightforward process. We just need to try alternate HTTP methods to see how they are handled by the web server and the web application. While many automated vulnerability scanning tools can consistently identify HTTP Verb Tampering vulnerabilities caused by insecure server configurations, they usually miss identifying HTTP Tampering vulnerabilities caused by insecure coding. This is because the first type can be easily identified once we bypass an authentication page, while the other needs active testing to see whether we can bypass the security filters in place.
We can check what options are accepted by a web application:
To bypass, we just try the different verbs to see if they work.
Bypassing Security Filters
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.
For example:
Prevention
Insecure Configuration
HTTP Verb Tampering vulnerabilities can occur in most modern web servers, including Apache, Tomcat, and ASP.NET. The vulnerability usually happens when we limit a page's authorization to a particular set of HTTP verbs/methods, which leaves the other remaining methods unprotected.
The following is an example of a vulnerable configuration 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:
As we can see, this configuration is setting the authorization configurations for the admin web directory. However, as the <Limit GET> keyword is being used, the Require valid-user setting will only apply to GET requests, leaving the page accessible through POST requests. Even if both GET and POST were specified, this would leave the page accessible through other methods, like HEAD or OPTIONS.
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:
We can see that the authorization is being limited only to the GET method with http-method, which leaves the page accessible through other HTTP methods.
Finally, the following is an example for an ASP.NET configuration found in the web.config file of a web application:
Once again, the allow and deny scope is limited to the GET method, which leaves the web application accessible through other HTTP methods.
The above examples show that it is not secure to limit the authorization configuration to a specific HTTP verb. This is why we should always avoid restricting authorization to a particular HTTP method and always allow/deny all HTTP verbs and methods.
If we want to specify a single method, we can use safe keywords, like LimitExcept in Apache, http-method-omission in Tomcat, and add/remove in ASP.NET, which cover all verbs except the specified ones.
Finally, to avoid similar attacks, we should generally consider disabling/denying all HEAD requests unless specifically required by the web application.
Insecure Coding
While identifying and patching insecure web server configurations is relatively easy, doing the same for insecure code is much more challenging. This is because to identify this vulnerability in the code, we need to find inconsistencies in the use of HTTP parameters across functions, as in some instances, this may lead to unprotected functionalities and filters.
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. It is always advised to expand the scope of testing in security filters by testing all request parameters. This can be done with the following functions and variables:
PHP
$_REQUEST['param']
Java
request.getParameter('param')
C#
Request['param']
Last updated