Http verb tempering: bypassing web authentication and authorization

Hypertext transfer protocol (HTTP) gives you list of methods that can be used to perform actions on the web server. Many of these methods are designed to help developers in deploying and testing HTTP applications in development or debugging phase. These HTTP methods can be used for nefarious purposes if the web server is misconfigured. Also, some high vulnerability like Cross Site Tracing (XST), a form of cross site scripting using the server's HTTP TRACE method, is examined.

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:

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

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.

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:

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:

Example Security Constraint Policy