In HTTP methods, GET and POST are most commonly used by developers to access information provided by a web server. HTTP allows several other method as well, which are less known methods. Following are some of the methods:

HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT

Many of these methods can potentially pose a critical security risk for a web application, as they allow an attacker to modify the files stored on the web server, delete the web page on the server, and upload a web shell to the server which leads to stealing the credentials of legitimate users. Moreover, when rooting the server, the methods that must be disabled are the following:

PUT: This method allows a client to upload new files on the web server. An attacker can exploit it by uploading malicious files (e.g. an ASP or PHP file that executes commands by invoking cmd.exe), or by simply using the victim’s server as a file repository. DELETE: This method allows a client to delete a file on the web server. An attacker can exploit it as a very simple and direct way to deface a web site or to mount a Denial of Service (DOS) attack. CONNECT: This method could allow a client to use the web server as a proxy TRACE: This method simply echoes back to the client whatever string has been sent to the server, and is used mainly for debugging purposes of developers. This method, originally assumed harmless, can be used to mount an attack known as Cross Site Tracing, which has been discovered by Jeremiah Grossman.

If an application requires any one of the above mentioned, such as in most cases REST Web Services may require the PUT or DELETE method, it is really important to check that their configuration/usage is properly limited to trusted users and safe environment. Many web environments allow verb based authentication and access control (VBAAC). This is basically nothing but a security control using HTTP methods such as GET and POST (usually used). Let’s take an example to make you understand better. JAVA EE web XML file [xml] /auth/* GET POST root [/xml] In the above example, the rule is limited to the /auth directory to root role only. However, this limitation can be bypasses using HTTP verb tempering even after limited/restricted access to the mentioned role. As we can see, the above mentioned configuration has only restricted the same using GET and POST methods only. We can easily bypass this with the use of the HEAD method; you can also try any other HTTP methods as well such as PUT, TRACK, TRACE, DELETE, etc. Also, you can try to bypass the same by sending arbitrary strings such as ASDF as an HTTP verb (method). Following are some conditions where bypassing is possible:

It has GET functionality that is not idempotent or execute an arbitrary HTTP Method It uses a security control that lists HTTP verbs The security control fails to block HTTP methods that are not listedThese are the most common scenarios where you can bypass the same. It also depend upon rule misconfiguration.

How we can bypass VBAAC with HTTP methods

Using HEAD method As mentioned above, the HEAD Method is used to fetch a result similar to GET but with no response body. Imagine a URL in your application that is protected by security constraints that restrict access to the /Auth directory with GET and POST only. http://httpsecure.org/auth/root.jsp?cmd=adduser If you try to force browse to the URL in a browser, a security constraint will check the rule to see whether the requested resource and requestor are authorized or not. The first rule will check the HTTP method as it came from the browser, so it should be a GET or POST method that’s stopped by the security constraint. If you use a browser proxy such as BurpSuite to intercept the request and craft it by changing GET to HEAD method, since HEAD method is not listed in the security constraint the request willnot be blocked. So the adduser function will be successfully invoked and you will get the empty response back in the browser due to HEAD functionality. Using Arbitrary HTTP Verbs Most of the platforms allow the use of arbitrary HTTP verbs such as PHP, JAVA EE. These methods execute similar to a GET request, which enables you to bypass the same. Most importantly, using the arbitrary methods response will not be stripped as it is for the HEAD method. You can see the internal pages easily. With the using arbitrary method, instead of the HEAD method page source code can be viewed. Some Vendors Allow HEAD Verbs Many server vendors allow HEAD verbs by default, such as: APACHE 2.2.8 JBOSS 4.2.2 WEBSPERE 6.1 TOMCAT 6.0 IIS 6.0 WEBLOGIC 8.2 Allowing the HEAD method is not a vulnerability at all, as it is a requirement in the RFC. Let’s have a look at some of the most popular outdated application security mechanisms to see if we can use them to bypass VBAAC.Following are the servers which may get affected by VERB tampering techniques. JAVA EE Allow HTTP Verbs in Policy -YES Bypassing Possible – YES HEAD can be in policy – YES .htaccess Allow HTTP Verbs in Policy – YES Bypassing Possible – YES (if not set) HEAD can be in policy – YES ASP.NET Allow HTTP Verbs in Policy – YES Bypassing Possible – YES (if not set) HEAD can be in policy – YES Java EE Containers Let’s consider the following security constraint policy: [bash] Example Security Constraint Policy Protected Area <!– Define the context-relative URL(s) to be protected –> /auth/security/ <!– If you list http methods, only those methods are protected –> POST PUT DELETE GET … [/bash] In the above mentioned code, listed methods are protected, so this rule will only trigger if a request for anything in the /auth/security directory uses a verb in the list. The best way to implement this policy would be to block any method that is not listed, butthat is not the way these mechanisms currently behave, and you can see that the HEAD verb is not in this list. So, forwarding the HTTP HEAD request will bypass this policy entirely, and after that, the application server will pass the request to the GET handler. The right approach to secure a JAVA EE is to remove all the elements from this policy, which simply applies this rule to all the HTTP methods, but if you still want to restrict access to specific method, then you need to setup two policies as mentioned below. [java] site / GET … site /* … [/java] So, the first policy denies a GET request to access and second policy denies all. ASP.NET Authorization Let’s have a look at the ASP.NET authorization security mechanism configuration, which is vulnerable to bypass with VBAAC. [vb] [/vb] In the above mentioned rule, the user JOE can only submit a POST request. In this example, this cannot be bypassed, the reason being GET methods are allowed to everyone. So, there are no securities to bypass using the HEAD method. [bash] [/bash] This one is vulnerable to bypass using HEAD method. This is possible because .Net implicitly inserts an “allow all” rule in to each authorization. After listing their role entitlements appropriately, append a “deny all” rule. [bash] [/bash] This will ensure that the only requests that pass the authorization check are those that have a specific HTTP verb that is in the authorization rule. Some Points to remember

  1. Always enable deny all option
  2. Configure your web and application server to disallow HEAD requests entirely Thanks for reading

Sources

Test HTTP Methods