Tampering with HTTP requests bypassing Web authorization and authentication

first, What is the HTTP request 　　

Hypertext Transfer Protocol (HTTP) provides a variety of request methods to communicate with a web Server. Of course, Most methods are designed 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 Tracing (XST) is a high-risk vulnerability that can take advantage of HTTP trace Requests.
Get and post are the most common requests for developers to get server information, not one of Them.

You can enumerate common HTTP requests: HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT

In theory, because these requests allow an attacker to modify files stored on a Web server, or to delete Web pages on a server, or even to upload web shells and obtain user identity information, They can potentially create a serious security Vulnerability.

For security reasons, The server root privilege must disable the following request:

PUT: allows uploading of new files to the Web Server. An attacker could upload a malicious file (such as a asp/php file that invokes the Cmd.exe Command) or use the victim server to store its own files.

Delete: allows you to delete files on the Web Server. Attackers can simply and brutally smear victims ' websites or implement DDoS attacks.

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

TRACE: any string sent to the server can be echoed on the Client. This request was originally intended to help the developer Debug. But this seemingly harmless request, but Jeremiah Grossman found can be exploited to implement XST attacks.

Even though some Web services often use put or delete requests, it's important to be cautious when we really encounter requests like these, to make sure that these requests are made 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 look at the following example:

JAVA EE web XML file<web-resource-<< span= ">a href=" http://resources.infosecinstitute.com/ collection/">collection>/auth/*getpost root

Such a setting is to tell the HTTP Servlet's container to allow only user roles to be root users, and to get the resources under the path of/auth/* through get and post Requests. At first glance, the code qualifies the user for access, as if there were no problems. however, we can circumvent the restrictions by tampering with HTTP requests! Why? Because he does not restrict other HTTP requests should be rejected by the server!

We can use head or other non-get/post requests, such as put, track, TRACE, delete, etc., or can also try to send arbitrary strings (such as asdf), It is extremely easy to circumvent this rule, to obtain the/auth/* path of the File.

Summarize the scenarios where bypassing may occur:

Allow a GET request of a non-idempotent or allow arbitrary HTTP methods

Control security by listing HTTP requests only

Cannot disable HTTP requests that are not listed

These are some of the most common scenarios where bypassing Occurs. Various permutations or details vary with the actual server Configuration. But the principle behind the seemingly complex practical case is the same, original Aim.

second, How to use HTTP Verb tampering bypass VBAAC

1. Head Request

As mentioned above, the head request is similar to get, except that the server does not return the body of the message in Response. Imagine that there is a URL in your app that is still extremely insecure if it is protected only by the "deny get and post Get/auth path files" rule.

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

If you force the browser to access the url, the security mechanism is triggered to check whether the requesting resource and requester are compliant with the authorization Rules. The first, of course, is to check and block the Get and post requests sent by the Browser. At this point, if you use a browser proxy, such as suite burp, replace the intercepted GET request with Head. Since head is not included in the security constraint rules, the AddUser command will be successfully invoked, and your browser will get an empty message body as a response to the head Request.

2. Any HTTP request

Most platforms, including php, JAVA ee, are allowed to use arbitrary HTTP requests by Default. These requests can replace the get bypass Rule. What's more, using any HTTP request allows you to see internal pages, even Web source code, which the head cannot do. Some server vendors allow head requests, and the following server vendors allow head requests by default:

APACHE 2.2.8

JBOSS 4.2.2

Webspere 6.1

TOMCAT 6.0

IIS 6.0

WEBLOGIC 8.2

On the surface, allowing the head method to be used is not a vulnerability because the RFC also has this Requirement. Let's take a look at some of the most popular application security mechanisms that will give us an opportunity to bypass VBAAC (verb-based authentication and Access control). The following are some of the servers that may be affected by tampering requests:

Does the server type allow HTTP requests?　　Is it possible to bypass? is the head request available?

JAVA EE Yes Yes Yes

. htaccess Yes Yes (default Configuration) Yes

asp. Yes (default Configuration) Yes

third, How to prevent HTTP Verb tampering 3.1 JAVA Security Constraints

How to prevent HTTP Verb tampering JAVA ee container, Let's look at the following security constraint policy:

Example Security Constraint policyprotectedarea/auth/security/*postputdeleteget ...

In the above code, the engineer enumerates and restricts the methods of post, PUT, DELETE, get, etc. therefore, The security constraint policy is triggered only when the browser uses these requests that are listed in the table to fetch files under the/auth/security/* path.

therefore, It is the best solution to perfect this rule to disable other unlisted methods as Well. unfortunately, The above strategy is not so rigorous at the Moment. For example, because head is not listed, it is not difficult to circumvent this strategy by using head Requests. Ensure that Java EE security is properly opened by removing all from the security constraint policy and making the security constraint policy specific to all HTTP request methods. however, If you still want to restrict certain methods, we recommend that you create a security constraint policy in 2 steps in the following ways.

site /* get...site/* ...

As above, the 1th policy rejects the Get request, and the 2nd policy rejects all the request METHODS.

3.2, ASP. NET Authorization

We know that the security mechanism for ASP. net authorization is likely to be bypassed, and let's take a few examples to illustrate it.

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

In this piece of code:

Allow user Joe to send a POST request

Allow all users to send get requests

Reject all users from sending a POST request

Because 2nd allows all users to send a get request, there is no need to bypass the head, and there is no security whatsoever. Don't think your IQ has been insulted, let's keep looking down. The following code makes some restrictions, but still gets bypassed by Head.

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

The reason is that the head request is not within the limit after matching the following rule by Article.

Allow user root to send a GET request

Allow user Joe to send a POST request

Deny all users send post, GET request

Because. NET silently inserts a rule at the end of all rules that allows all users to send all Requests. therefore, the head request will be Released. To avoid this situation, we should add "deny all users send all requests" after the last Rule. so, with the following code:

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

This ensures that only certain users who are in the rule whitelist are allowed to send specific HTTP Requests.

Summarize:

In the case of a business license, add "deny all".

Configure your Web server and application server to completely disable head Requests.

Tampering with HTTP requests bypassing Web authorization and authentication