Introduction to HTTP response splitting attacks

In this article, we will discuss what HTTP response splitting is and how attack behaviors are carried out. Once we fully understand the principle of its occurrence (which is often misunderstood), we can explore how to use response splitting to execute cross-site scripting (XSS ). Next, we will naturally discuss how to use this server to organize CSRF (Cross-Site Request Forgery) attacks if the target website has a response splitting vulnerability. Finally, let's take a look at the preventive measures that can defend against these attacks. If you are interested in this topic, you may wish to continue reading it.

What is HTTP Response Splitting?

First, let's imagine a page with multiple language options. The default language of this page is English, but it also has a drop-down menu, allowing us to switch the language of the entire page at the same time after selecting the corresponding language. For example, according to the initial page configuration, 302 redirects back to the result of http://www.bkjia.com/index. php? Lang = en. But for users from Germany, of course they want the page content to be displayed in German, then they can select from the drop-down menu in the alternate language. This causes 302 to repoint to the German page that will be sent to the server-http://www.bkjia.com/index. php? Lang = german. The user's browser will follow the redirection and display the German page normally.

Now let's think about the subject content that HTTP 302 points back to the response. The content is as follows:

HTTP/1.1 302 Moved Temporarily
Location: http://www.bkjia.com/index. php? Lang = en
Or:

HTTP/1.1 302 Moved Temporarily
Location: http://www.bkjia.com/index. php? Lang = german
You may have discovered that the only change is the lang parameter value. That is to say, this value is controlled by the user. We can set this value to any desired content. This feature causes the occurrence of HTTP response splitting attacks.

In this case, we do not set the parameter value to "german", but set it according to the following content:

A) The value 'German'
B) CR/LF-% 0d % 0a
C) A response with Content Length 0 [the reason why the Length is set to 0 is that this section does not matter.]
D) CR/LF-% 0d % 0a
E) A response which contains malicious content [for example, JavaScript can be set to automatically download malware when the page is accessed]
Let's take a look at the content of c)-this is the first response. The HTTP protocol works in a way that a request corresponds to a response, so for this request -- that is, http://www.bkjia.com/index. php? Lang = german's response is carefully designed. In fact, we don't care about the response itself and its Content. All we want is to set Content-Length: 0 as its response header.

CR/LF (that is, the carriage return line break) is the boundary between responses. So as long as we add CR/LF content as shown in d), the second round of response will start, and this is completely normal according to the HTTP protocol. In the next round of response, we can add a large amount of information. For example, if we want to display a message "Hello, you have been phished" (which means 'hello, you have already been recruited '), there is no obstacle in front of us. You only need to enter the following content for easy implementation:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 41
Hello, you have been phished
I still feel a little confused? Let's summarize it again. The attacker controls the parameters and sends a request that will generate two responses. Both responses are organized by the attacker and target the server. The first response is intended to respond to requests that convert the page to German, and the second response (so far) has not been explained, it only suspends temporarily because the response does not have a corresponding request mapped. Remember that HTTP requires a response (no matter what the content code is), but it requires a response that corresponds to all requests. Therefore, the pending HTTP response cannot work.

Please read carefully... This is precisely what most people (even myself for a long time) have not figured out. .

Assume that the request sent by him is:

GET/branches.html HTTP/1.1
Host: www.2cto.com
After sending the first request containing the "customizable content" parameter, the system immediately sends the second request, which is exactly "Hello, you have been phished "field ing object. The two requests correspond to two responses. Do you understand?

Haha, I'm afraid you are still confused. Although you may already know the entire ing process, you still don't understand how this attack affects others. After all, all the actions taken by the attacker occur on his own computer, and the modified requests are limited to him... That is to say, only one of them will be affected. To be honest, why should attackers attack themselves? This seems unreasonable. However, I want to point out that this is a key link for proxy servers or some devices located in the intermediate frame and cache to accept requests and responses.

Attackers must hide behind the proxy server and use the proxy to send their requests to the target server on the Internet. If he wants to infect other users, these victims must also be placed after the same proxy server. Therefore, Let's sum up again (please be patient ...)

A) the attacker sends a request containing one value and two responses, which are separated by % 0d % 0a. In this example, the request content is as follows:

A http://www.bkjia.com/index. php? Lang = german % 0d % 0aContent-Length: % 200% 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aContent-Length: % 2041% 0d % 0 aHello, you have been phished
B) The request is sent at www.2cto.com... But it is important that it is passed through the intermediate proxy server. Therefore, on the proxy server, the first request is mapped to the first response, and the second response is suspended because no matching request is available.

C) after the first request is sent, the attacker will immediately send a new request (the second request) to the target website (also through the proxy server). The content is as follows:

GET/branches.html HTTP/1.1
Host: www.2cto.com
After receiving branches.html, The d)proxy will map it to the second response ('you have been phished') immediately '). The requests sent to branches.html will not show the bank's branch list, but direct to malicious web pages. Yes, this is true for every visitor, not just for attackers. Why? Because this is exactly how the cache proxy server is processed... The cache response is frequently requested. Also, if a request sent to branches.html always generates a static list of information about the bank branch, the proxy server will almost certainly call the cache to respond to the request. In other words, a request to branches.html will automatically return a response from the cache. Under the attacker's arrangement, the proxy server's cache content is infected and forced to return malicious responses rather than the original static list ...... This situation continues until the cache expires.

We hope that after the above detailed introduction, you will have a clear concept of HTTP response splitting. This is the top priority of the article, so read it several more times. The key lies in that the second request sent by the attacker will force the proxy server to follow the ing mode corresponding to the second response of the second request. Once you understand this, the entire concept should be clear: Cross-Site Scripting through response splitting

It should be noted that I do not intend to explain in detail the cross-site scripts and their specific types. You can easily find a large number of articles on this topic on the Internet (I will provide some reference links at the end). By reading this article, you can fully understand this concept.

Now we are quite familiar with response splitting, so we should start from the attacker's perspective to gain further gains. Can we run JavaScript on the target computer by responding to the split and try to obtain full control over its browser? The answer is yes. As long as we expand some of the examples we provided earlier, this goal can be achieved smoothly.

We should remember that the second round of malicious response we designed in the previous article only uses a simple page to tell the user that "you have already made a move ". To achieve a more evil purpose, we need to write some JavaScript code to replace the original simple page. Unlike pages that can only implement the display function, JavaScript can actually run in users' browsers. Attackers can control the browser of the target user based on the content of JavaScript code. Therefore, if you want to extend the example above, the attacker will design the following URL:

A http://www.bkjia.com/index. php? Lang = german % 0d % 0aContent-Length: % 200% 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aContent-Length: % 20% 0d % 0 aalert ('run JavaScript on your computer ')
Then, as before, the request will be sent to branches.html, And the request containing malicious JavaScript content will naturally be mapped to the second response. The proxy will be infected first, and when another user of the same proxy server is running branches.html, the JavaScript code will intrude into his computer.

If the target site has a vulnerability in XSS, we can use the same logic to attack it. In this case, the vulnerability parameter is the main body of the script. Therefore, we need to replace the JavaScript part in the previous example.

In my example, the JavaScript content is very intuitive and the result is just a small warning box. In fact, JavaScript can be compiled more complex, and attackers can gain full control over the target user's browser and ultimately control the computer. A development framework named BeeF can be of great help to attackers. They only need to write a small piece of JavaScript and then import it into the BeeF controller. The victim's computer is in danger.

Cross-Site Request Forgery through response splitting

As before, I am not going to detail the ins and outs of CSRF attacks here. Let's get the relevant details from the reference summary at the end of the article. Simply put, the victims of CSRF attacks perform some "implicit" operations without knowledge. It should be emphasized that these operations are basically the type of operation that the victim does not want to perform when the victim is killed.

As a prerequisite for a CSRF attack, the victim must first log on to the site where the operation is performed. Therefore, if the attacker wants to induce the victim to perform the "delete my Google profile" operation, the user must first log on to the corresponding Google system to perform the operation smoothly. In addition, attackers must be able to predict the exact structure including parameter values. Take the bank transfer operation as an example. The specific amount must be accurate and valid, for example, GET/transfer/php? Acc1 = 1000 & acc2 = 2000 & amt = 900. In this way, as long as the user sends a similar GET command after logging on to www.2cto.com, the transfer from acc1 to acc2 will be automatically executed.

In CSRF attacks, attackers always use some tricks to induce users to click links, take social psychological tactics, or allow users to access a page under the control of attackers; in short, although the user is a self-sent request in theory, the victim does not know what content is actually executed in the background.

Now let's go back to the question of splitting. Everyone should remember how the attacker turned to the branches.html page and injected malicious JavaScript content into it to try to run scripts on the user's browser. In CSRF attacks, we need to ensure that the behavior (such as the aforementioned transfer operation URL) is automatically executed when the user accesses the infected page. In other words, branches.html contains a small image and is loaded along with the page. The label of this image will send content to the server of www.2cto.com as/transfer/php? Acc1 = 1000 & acc2 = 2000 & amt = 900 requests.

Therefore, in response to the split attack, the content of the entire malicious URL is as follows:

A http://www.bkjia.com/index. php? Lang = german % 0d % 0aContent-Length: % 200% 0d % 0 aHTTP/1.1% 20200% 20OK % 0d % 0aContent-Type: % 20 text/html % 0d % 0aContent-Length: % 20% 0d % 0a </body> The final result is that every user accesses the page (branches.html) of the infected website through the proxy and logs on to the www.2cto.com site on the tab of another browser, the money will be smoothly transferred to the account specified by the attacker.
Sample Code:

Now let's take a quick look at the PHP code types that respond to the split vulnerability. For beginners, we use a small HTML file as an example (resplit1.html), which contains a drop-down menu that allows users to select a language type. The details are as follows:

<HTML>
<BODY>
<Form name = "form" action = "resplit1.php" method = "GET">
<Select name = "lang">
<Option value = "EN"> English </option>
<Option value = "GER"> German </option>
</Select>
<Input type = "submit" name = "Submit" value = Submit> </INPUT>
</FORM>
</BODY>
</HTML>
After selecting the desired language type, you will certainly click the submit button, and this input behavior will be submitted to the PHP file named resplit1.php. The function of all the above Code is to intercept our input content, use it to create a URL for re-pointing, and then send it to 302 and re-pointing to the response. The resplit1.php file is as follows:

<? Php
$ Lang = $ _ GET ['lang ']
Header ("Location: http: // localhost/resplit2.php? Lang = $ lang ");
?>
Open the HTML file in the browser and place it in the Burp or any other type of proxy editor. In this case, pay attention to the response after we click submit on the first page. You will clearly find that the project you selected in the drop-down menu is actually the response header in the 302 response of the local machine. Therefore, if you want to modify this, you must wait until the request arrives at the server, the lang parameter value is edited using a malicious string (that is, two responses to a request we mentioned earlier ).

What resplit2.php does is to display the selected language types.

<? Php
$ A = $ _ GET ['lang '];
If (strcmp ($ a, 'en') = 0)
Echo "Language selected is English ";
Elseif (strcmp ($ a, 'Ger ') = 0)
Echo "Language selected is German ";
Else
Echo "No valid language selected ";
?>
Now, when I plan to perform a test, my PHP framework will remove the % 0d % 0a string from the response header. This default setting actually protects my PHP framework. However, if you are using an older version of the Framework, the default settings will not implement protection, resulting in code problems easily in CRLF. The filtering function mentioned here is shown in:

<? Php
$ Pattern1 = "/\ % 0d /";
$ Pattern2 = "/\ % 0a /";
$ Lang = $ _ GET ['lang '];
$ R = preg_match ($ pattern1, $ lang );
$ S = preg_match ($ pattern2, $ lang );
If ($ r> 0) | ($ s> 0 )){
Echo 'Carriage Return found in user input ';
Echo "<BR> ";
}
Else {
Header ("Location: http: // localhost/resplit2.php? Lang = $ lang ");
}
?>
We can write more efficient filters on our own. For example, we can add items containing only letters and numbers to the White List and directly block all other types; however, this is only an example of defensive code. If you forget to write these filters, you will be able to completely deliver your fate to the framework itself in use. If you are similar to the framework I use (APT library in Ubuntu 10.04), It's okay because of the built-in protection mechanism... Otherwise, you will have to pay a heavy price.

A large number of vulnerability categories have been detected. I provide a detailed list in the reference link at the end of the article.
Countermeasures:

◆ Response split attack: server-side authentication mechanism is used, and all users are prohibited from using the carriage return linefeed (CRLF) in any input requests related to the response header ).

◆ XSS attacks: the White List, blacklist filtering (input verification), and Escape HTML (output verification) are introduced ).

◆ CSRF attack: the AntiCsrf language symbol is used, so that attackers cannot accurately predict the Target Structure and cannot forge the target structure.

Conclusion:

Responding to a split-type attack only works when multiple users use the same proxy server to connect to different websites. Once the proxy server cache is infected, the user will be attacked when reading the page from the proxy server cache. However, please note that not all proxy servers have vulnerabilities in response to splitting, although this is a digress. If you are interested in learning more about this attack, I strongly recommend that you read the brilliant paper prepared by Amit Klein (see references 1 ).

References:

◆ Response split attack-http://packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf

◆ XSS attack-http://www.technicalinfo.net/papers/CSS.html

◆ XSS attack countermeasures-https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

◆ CSRF attack-https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

◆ CSRF attack measures-https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

◆ B browser development framework-http://beefproject.com/

◆ Learning PHP (Tutorial)-http://www.w3schools.com/php/

◆ PHP functions-http://php.net/quickref.php

◆ Exposed response splitting vulnerability summary list-http://cwe.mitre.org/data/definitions/113.html

Link: http://resources.infosecinstitute.com/http-response-splitting-attack/

From: 51cto.com