Tampering with HTTP requests by bypassing Web authorization and authentication

Tampering with HTTP requests by bypassing Web authorization and authentication
 What is an HTTP request?

Hypertext Transfer Protocol (HTTP) provides multiple request methods to communicate with web servers. Of course, the original intention of most methods is to help developers deploy and test HTTP applications during development or debugging. If the server is improperly configured, these request methods may be used for some illegal purposes. For example, cross-site tracking (XST) is a high-risk vulnerability. This cross-site scripting can use http trace requests.

GET and POST are the most common requests for developers to obtain server information. Common HTTP requests can be listed as follows:

HEAD

GET

POST

PUT

DELETE

TRACE

OPTIONS

CONNECT

Theoretically, these requests allow attackers to modify files stored on the web server, delete web pages on the server, or even upload web shells and obtain user identity information, both of them may create serious security vulnerabilities. In addition, for security reasons, the root permission of the server must be disabled for the following requests:

PUT: allows you to upload new files to the web server. Attackers can upload malicious files (such as ASP/PHP files that can execute the cmd.exe command) or use the victim server to store their own files.

DELETE: allows you to DELETE files on a web server. Attackers can simply and roughly target the victim's website or launch DDoS attacks.

CONNECT: allows the client to configure the server as a proxy.

TRACE: any strings sent to the server can be displayed on the client. This request was originally used to help developers debug the request. But this seemingly harmless request was discovered by Jeremiah Grossman to be exploited for XST attacks.

Even though some Web services often use PUT or DELETE requests, when we encounter such requests, be careful to confirm that these requests are sent by trusted users in a secure environment. Many network environments use request-based authentication and access control policies (VBAAC ). But will it be bypassed? Let's take a look at the following example:

Java ee web XML file

A href = "http://resources.infosecinstitute.com/collection/"> collection>

/Auth /*

GET

POST

Root

This setting tells the HTTP Servlet Container that only the root user is allowed to obtain resources in the path/auth/* through GET and POST requests. At first glance, the Code limits the user access permissions, and it seems that there is no problem. However, we can tamper with HTTP requests to bypass the restrictions! Why? Because it does not limit other HTTP requests to be rejected by the server!

We can use HEAD or other non-GET/POST requests, such as PUT, TRACK, TRACE, and DELETE, or try to send arbitrary strings (such as ASDF ), attackers can easily bypass this rule to obtain files in the/auth/* path.

Let's summarize the possible bypassing situations:

Allow non-idempotent GET requests or arbitrary HTTP methods

Control Security by listing HTTP requests only

Do not disable HTTP requests not listed

The above are the most common scenarios for bypassing. Various arrangement combinations or differences in details vary with the actual server configuration. However, the principles behind seemingly complex actual cases are the same.

How to Use HTTP Verb Tampering to bypass VBAAC

HEAD request

As mentioned above, the HEAD request is similar to the GET request, except that the server does not return the message body in response. Suppose your application has a URL. If you only use the "Deny GET and post get/auth path file" rule to protect it, it is still extremely insecure.

Http://httpsecure.org/auth/root.jsp? Cmd = adduser

If you force the browser to access the URL, the security mechanism will be triggered to check whether the requested resource and requester comply with the authorization rules. The first is to check and block the GET and POST requests sent by the browser. In this case, you must use a browser proxy, such as Suite Burp, to replace the intercepted GET request with a HEAD. Because the HEAD is not included in the security constraint rules, the adduser command is successfully called, and your browser will get an empty message body as the response of the HEAD request.

 

Any HTTP Request

Most platforms, including PHP and java ee, allow arbitrary HTTP requests by default. These requests can replace GET bypass rules. What's more terrible is that using any HTTP request allows you to see internal pages, or even webpage source code, which cannot be handled by the HEAD. Some server vendors allow HEAD requests. The following server vendors allow HEAD requests by default:

APACHE 2.2.8

JBOSS 4.2.2

Web spere 6.1

TOMCAT 6.0

In IIS 6.0

WEBLOGIC 1, 8.2

On the surface, allowing the HEAD method is not a vulnerability because RFC also has this requirement. Let's see if some of the most popular application security mechanisms allow us to bypass VBAAC. The following are some servers that may be affected by tampering requests:

Server Type

Allow HTTP requests?

Can it be bypassed?

Is the HEAD Request available?

JAVA EE

YES

YES

YES

. Htaccess

YES

YES (default configuration)

YES

ASP. NET

YES

YES (default configuration)

YES

How to Prevent HTTP Verb Tampering

 

To prevent the HTTP Verb Tampering java ee container, let's take a look at the following security constraint policies:

Example Security Constraint PolicyProtected Area/auth/security/*POSTPUTDELETEGET...

In the above Code, the great siege lions list and restrict POST, PUT, DELETE, GET and other methods. Therefore, only when the browser uses The security constraint policy is triggered only when the requests listed in the table obtain files in the/auth/security/* path.

Therefore, disabling Other unlisted methods is the optimal solution to improve this rule. Unfortunately, these policies are not so rigorous. For example, because the HEAD is not listed, it is not difficult to bypass this policy using HEAD requests. The correct way to enable java ee security is to remove all And make the security constraint policy target all HTTP request methods. If you still want to restrict some specific methods, we recommend that you create a security constraint policy in two steps by referring to the following method.

site/*GET...site/*...

 

As shown above, 1st policies will reject GET requests, while 2nd will reject all request methods.

ASP. NET authorization

We know that the security mechanism authorized by ASP. NET may be bypassed. Here are some examples.
 

verbs="POST" users="joe"/>verbs="GET" users="*"/>verbs="POST" users="*"/>

In the above Code:

Allow user joe to send POST requests

Allow all users to send GET requests

Reject POST requests from all users

Because 2nd requests allow all users to send GET requests, there is no need to use HEAD to bypass them, and there is no security at all. Don't think your IQ has been insulted. Let's continue to look at it. The following code imposes some restrictions but is still bypassed by the HEAD.

verbs="GET" users="root"/>verbs="POST" users="joe"/>verbs="POST,GET" users="*" />

The reason is that after matching the following rules one by one, the HEAD request is found to be out of the limit.

Allow the User root to send a GET request

Allow user joe to send POST requests

Reject POST and GET requests from all users

Because. NET will quietly insert a rule at the end of all rules to allow all users to send all requests. Therefore, HEAD requests are allowed. To avoid this situation, we should add "reject all requests sent by all users" after the last rule ". Therefore, the following code is available:

verbs="GET" users="root"/>verbs="POST" users="joe"/>verbs="*" users="*" />

In this way, only specific users in the Rule whitelist can be allowed to send specific HTTP requests.

Summary

Add "deny all" when the business permits ".
 

Configure your web server and application server to completely disable HEAD requests.