How to find website is vulnerable to HTTP Verb Tampering?

Hello Friends, Today we will be learning How to find that a website is vulnerable to HTTP Verb Tampering. HTTP web tampering usually occurs on websites which uses HTTP verbs for authorization (i.e. like providing access to some directory, web resource or simply content) but doesn’t restricts what all HTTP verbs should be permitted. Hackers exploits HTTP verbs via passing other unrestricted verbs or simple text strings to gain access of the restricted resouces.

But everybody must be in deep thought that what are these HTTP verbs? HTTP Verbs also known as HTTP methods are basically HTTP Keywords to indicate the desired action to be performed on the identified resource. HTTP offers vast variety of HTTP verbs, some of them are mentioned below:

• OPTIONS
• GET
• HEAD
• POST
• PUT
• DELETE
• TRACE
• CONNECT

Most of us are aware with GET and POST methods only. You can read about other methods in detail on Wikipedia or some HTTP book.

Many web server authentication mechanism uses HTTP Verb based authentication and access control. These type of security mechanisms normally use selected HTTP verbs for access control rules. For example, an web administrator can configure a Web server to allow unrestricted access to a Web page using HTTP GET requests, but restrict POSTs to administrators only. However, many implementations of verb-based security mechanisms enforce the security rules in an unsecure manner, allowing access to restricted resources by using alternative HTTP methods (such as HEAD) or even arbitrary character strings. For example, Java Platform Enterprise Edition (Java EE) supports verb-based authentication and access control through the web.xml configuration file. In Java EE, one can limit access to the admin/ directories for “admin” users by adding the following to web.xml:

<security-constraint>
<web-resource-collection>
<url-pattern>/admin/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>

These security rules ensure that GET or POST requests to admin/ directories from non admin users will be blocked. However, HTTP requests to admin/ directories other than GET or POST will not be blocked. While a GET request from a non admin user will be blocked, a HEAD request from the same user will not. Unless the administrator explicitly configures the Web server to deny all methods other than GET and POST, the access control mechanism can be bypassed simply by using different methods that are supported by the server. Other examples of Web servers that are affected by this issue include IIS 6.0, Apache 2.2.8, and TomCat 6.0.
In some Web servers–for example, Apache 2.2/PHP–it is even possible to bypass the access control mechanism by using arbitrary character strings for HTTP methods. Such Web servers implement default handlers for requests that are not bound to a specific HTTP method. Unlike an HTTP Servlet where a GET request is only handled if a doGet() is defined, some Web servers attempt to process any and all methods including unknown methods. Thus, by replacing a legitimate method with an arbitrary one (MPRV instead of GET) the attacker can exploit vulnerabilities in the internal processing logic and bypass the access control mechanism.

If you are able to analyze your application via simple HTTP status codes (200 OK, 501 Error, etc) – then the following bash script will test all available HTTP methods and best way to automatically test all allowed methods.

#!/bin/bash

for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;

do
printf “$webservmethod ” ;
printf “$webservmethod / HTTP/1.1\nHost: $1\n\n” | nc -q 1 $1 80 | grep “HTTP/1.1”

done

So the best way to prevent HTTP verb tampering is to restrict use of limited HTTP verbs and best case is just avoid using HTTP verbs for access controls.

Note: Verb tampering attacks exploit either configuration flaws in the access control mechanism or vulnerabilities in the request handlers’ code. As presented in the example above, blocking requests that use non-standard HTTP methods is not enough because in many cases an attacker can use a legitimate HTTP method like HEAD.

That’s all friends. Keep Connected to keep learning.