Skip to content

HTTP Verb Tampering

OWASP

OWASP Web Security Testing Guide 4.2 > 2. Configuration and Deploy Management Testing> 2.6. Test HTTP Methods

ID Link to Hackinglife Link to OWASP Description
2.6 WSTG-CONF-06 Test HTTP Methods - Enumerate supported HTTP methods using OPTIONS. - Test for access control bypass (GET->HEAD->FOO). - Test HTTP method overriding techniques.

HTTP method tampering, also known as HTTP verb tampering, is a type of security vulnerability that can be exploited in web applications. HTTP method tampering occurs when an attacker modifies the HTTP method being used in a request to trick the web application into performing unintended actions.

More about HTTP methods.

http request

Test Objectives

  • Enumerate supported HTTP methods.
  • Test for access control bypass.
  • Test HTTP method overriding techniques.

Enumerate with OPTIONS:

1
curl -v -X OPTIONS <target>

Test access control bypass with a made-up method:

1
curl -v -X FAKEMETHOD <target>

Or test access control bypass with other methods.

PUT

After enumerating methods with Burpsuite:

1
2
OPTIONS /uploads HTTP/1.1
Host: example.org

We obtained as response:

1
2
3
4
HTTP/1.1 200 OK
Date: ....
....
Allow: OPTIONS,GET,HEAD,POST,PUT,DELETE,TRACE,PROPPATCH,COPY,MOVE,LOCK

Then, we can try to upload a file by using Burpsuite. Typical payload:

1
2
3
4
5
PUT /test.html HTTP/1.1
Host: example.org
Content-Length: 25

<script>alert(1)</script>

Try to upload a file by using curl. Typical payload:

1
2
curl https://example.org --upload-file test.html
curl -X PUT https://example.org/test.html -d "<script>alert(1)</script>"

DELETE

Try to delete a file by using Burpsuite. Typical payload:

1
2
DELETE /uploads/file1.pdf HTTP/1.1
Host: example.org

Try to delete a file by using curl. Typical payload:

1
curl -X DELETE https://example.org/uploads/file1.pdf

TRACE

The TRACE method (or Microsoft’s equivalent TRACK method) causes the server to echo back the contents of the request. This led to a vulnerability called Cross-Site Tracing (XST), which could be used to access cookies that had the HttpOnly flag set. The TRACE method has been blocked in all browsers and plugins for many years; as such, this issue is no longer exploitable. However, it may still be flagged by automated scanning tools, and the TRACE method being enabled on a web server suggests that is has not been properly hardened.

CONNECT

The CONNECT method causes the web server to open a TCP connection to another system, and then pass traffic from the client to that system. This could allow an attacker to proxy traffic through the server, in order to hide their source address, access internal systems or access services that are bound to localhost. An example of a CONNECT request is shown below:

1
2
CONNECT 192.168.0.1:443 HTTP/1.1
Host: example.org

Testing for Access Control Bypass

If a page on the application redirects users to a login page with a 302 code when they attempt to access it directly, it may be possible to bypass this by making a request with a different HTTP method, such as HEAD, POST or even a made up method such as FOO. If the web application responds with a HTTP/1.1 200 OK rather than the expected HTTP/1.1 302 Found, it may then be possible to bypass the authentication or authorization.

1
2
HEAD /admin/ HTTP/1.1
Host: example.org

1
2
3
HTTP/1.1 200 OK
[...]
Set-Cookie: adminSessionCookie=[...];

Testing for HTTP Method Overriding

Some web frameworks provide a way to override the actual HTTP method in the request. They achieve this by emulating the missing HTTP verbs and passing some custom headers in the requests. For example:

  • X-HTTP-Method
  • X-HTTP-Method-Override
  • X-Method-Override

To test this, consider scenarios where restricted verbs like PUT or DELETE return a 405 Method not allowed. In such cases, replay the same request, but add the alternative headers for HTTP method overriding.

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.

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.

Apache

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:

Code: xml

1
2
3
4
5
6
7
8
<Directory "/var/www/html/admin">
    AuthType Basic
    AuthName "Admin Panel"
    AuthUserFile /etc/apache2/.htpasswd
    <Limit GET>
        Require valid-user
    </Limit>
</Directory>

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.

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:

Code: xml

1
2
3
4
5
6
7
8
9
<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>

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.

ASP.NET

Finally, the following is an example for an ASP.NET configuration found in the web.config file of a web application:

Code: xml

1
2
3
4
5
6
7
8
<system.web>
    <authorization>
        <allow verbs="GET" roles="admin">
            <deny verbs="GET" users="*">
        </deny>
        </allow>
    </authorization>
</system.web>

Once again, the allow and deny scope is limited to the GET method, which leaves the web application accessible through other HTTP methods.

Insecure coding

Let's consider the following PHP code from a File Manager feature:

Code: php

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

If we were only considering Command Injection vulnerabilities, we would say that this is securely coded. The preg_match function properly looks for unwanted special characters and does not allow the input to go into the command if any special characters are found. However, the fatal error made in this case is not due to Command Injections but due to the inconsistent use of HTTP methods.

We see that the preg_match filter only checks for special characters in POST parameters with $_POST['filename']. However, the final system command uses the $_REQUEST['filename'] variable, which covers both GET and POST parameters.

Last update: 2025-01-18
Created: September 16, 2024 20:21:30