Practical Web Security Testing: HTTP truncation (Smuggling vulnerability) (1)

Bkjia.com exclusive Article] In this article, we will detail the Security Testing Technology for HTTP truncation and HTTP smuggling attacks. We will use examples to demonstrate how to use some features of the HTTP protocol, or use the vulnerabilities of Web applications or the different interpretations of HTTP messages by different proxies to launch these two attacks.

I. Overview of HTTP truncation/smuggling Vulnerabilities

In this article, we will analyze two different attack technologies targeting specific HTTP headers: HTTP truncation and HTTP smuggling attacks. HTTP truncation attacks exploit a vulnerability that lacks input disinfection measures. This vulnerability allows intruders to insert CR and LF characters into the application response header, thus, the response is divided into two different HTTP messages. The attack targets are different from Cache Poisoning and cross-site scripting attacks. For the second attack method, attackers exploit the fact that some specially crafted HTTP messages may be parsed and interpreted differently as different proxies receive them. HTTP smuggling technology requires that you be familiar with the various proxies that process HTTP messages. Otherwise, you cannot launch such attacks.

The following describes the black box and gray box testing techniques for these vulnerabilities.

Ii. Black Box test of HTTP truncation attacks

Some web applications use some user input to generate some values in their response headers. The simplest example is redirection, because the target URL depends on some values submitted by the user. For example, if a user is required to make a selection between the standard web interface and the advanced web interface, the selection result will be passed as a parameter, this parameter is used to trigger redirection to the response header of the corresponding page. More specifically, if the value of the interface parameter is advanced, the application will respond to the following content:

Figure 1

After receiving this message, the browser will direct the user to the page specified by the Location header. However, if the application does not filter user input, attackers can insert the sequence % 0d % 0a in the interface parameter, this sequence represents the CRLF carriage return line used to separate rows. In this way, attackers can trigger a response. What is important is that any parser, such as the Web cache between the user and the web application, will interpret this response as two different responses. Therefore, attackers can cache the web to "inject viruses" to provide false content for subsequent requests. For example, in our previous example, assume that the attacker transmits the following content as the parameter interface:

Figure 2

The response from the software with vulnerabilities, that is, applications that do not strictly sanitize user input, is as follows:

Figure 3

The Web Cache will see two different responses. Therefore, if an attacker sends a request to the/index.html page immediately after sending the first request, the web cache will regard the request as matching the second response, and cache its content, so that all requests directed to victim.com/index.html through the web cache will receive the system fault message, that is, wait system down ". In this way, an attacker can effectively alter the image of the website in the minds of users who use the web cache. If the web cache is a reverse proxy of the Web application, users of this Web application will be affected throughout the internet. In addition, attackers can transmit JavaScript code fragments that initiate cross-site scripting attacks to these users, such as cookies. It should be noted that although the security vulnerability is located in an application, the attack targets users who use the application.

Therefore, in order to find this security vulnerability, penetration testers need to identify all user inputs that can affect the response in one or more headers, and check whether the user can inject a CR + LF sequence in it. The two most closely related headers are:

Location   Set-Cookie

In reality, it may be very complicated to successfully exploit this security vulnerability, because there are multiple factors that must be taken into account:

1. In order for the attacker to cache the forged response, each header must be set correctly. For example, the value of the Last-Modified header must be set to a future time. In addition, attackers must also damage the previous cache version of the target page by submitting a request header with a leading request containing "Pragma: no-cache" to prevent the page from being cached.

2. Even if the application does not filter the CR + LF sequence, it may still filter other characters required to launch the attack, such as characters <and>. At this time, attackers can try to use other encoding, such as UTF-7 encoding.

3. Some attack targets, such as ASP, will perform URL encoding on the path section in the Location header, such as www.victim.com/redirect.asp, so that the CRLF sequence does not work. However, they cannot query the part such? Interface = advanced) for such encoding, which means placing a leading question mark can bypass this filtering technology.