Web14: Security issues in the HTTP protocol

This article presents some security issues in the HTTP protocol, raised in two documents RFC 7230 and RFC 7231. Examples in the article about specific errors are referenced from OWASP.

1. Risks from intermediate factors

HTTP allows the use of intermediaries to respond to requests through a series of connections. There are three common intermediary elements: proxy, gateway and tunnel.

A request or response will have to go through points A, B and C. They can access sensitive information being transmitted, such as personal information of users or organizations. The lack of attention paid to security and privacy by intermediaries can lead to a wide range of potential attacks.

System developers and developers should consider privacy and security factors during the system design, coding and deployment process.

Users need to be aware of the dangers of using untrusted proxies or gateways.

2. Response Splitting

Response splitting (aka CRLF injection) is a popular web exploit technique. The attacker sends encoded data, in some request parameters, which is then decoded and repeated in a certain field of the response header.

If this data is a symbol representing the end of the response, and a subsequent response is initiated, the original response will be split into two and the content of the second response will be controlled by the attacker. The attacker can then make another request within the same persistent connection, and trick the recipient (including intermediaries) into believing that this second response is in response to the second request.

 3. Request Smuggling

Request smuggling is a technique that exploits differences in the processing of requests by different types of servers to hide seemingly harmless requests appended to the original request.

Let's consider the following example:

Suppose a POST request contains two 'Content-length' fields in the header with two different values. Some servers will deny this request (IIS and Apache), but others will not. For example, SunONE W/S 6.1 uses the Content-length field first, while sunONE Proxy 3.6 takes the Content-length field second.

Assuming SITE is the DNS of a SunONE W/S, located behind a SunONE Proxy, there is a poison.html file located on the SunONE W/S. Here's how to exploit HTTP Request Suggling based on inconsistencies in processing between two servers:

[Note that each line ends with a CRLF (''), except line 10]

Let's consider what happens when a request is sent to W/S through the Proxy server. First, the proxy will analyze the request from lines 1 to 7 (blue) and encounter two Content-Length fields. As mentioned above, it will ignore the first field and understand that the request body is 44 bytes long. Therefore, it treats the data from lines 8 to 10 as the first request body (from lines 8 to 10, the data is exactly 44 bytes long). The proxy will then analyze lines 11 to 14 (in red) as the client's second request.

Now let's see how W/S interprets the data above, as it is forwarded from the proxy. Unlike proxies, W/S will use the first Content-Length field and interpret it as follows: the first request has no body, and the second request starts from line 8 (note that W/S will parse from line 11 onwards as the value of the Bla field).

Next, let's see how the response is returned to the client. The request that W/S understands is 'POST /foobar.html' (from line 1) and 'GET /poison.html' (from line 8), so it will send the client 2 responses with the content of the foobar page. html and poison.html. The proxy understands that these 2 responses correspond to 2 requests: 'POST /foobar.html' (from line 1) and 'GET /page_to_poison.html' (line 11). The proxy will cache the content of the poison.html page corresponding to the URL 'page_to_poison.html' (cache poisoning). From there, when the client requests 'page_to_poison.html', it will receive the content of the poison.html page.

 4. Attack based on file path

Web servers frequently use their local file system to manage the mapping of file names in URIs to actual resources on the server. Most file systems are not designed to protect against malicious file paths. Therefore, the server needs to avoid accessing important system files.

For example, UNIX, Microsoft Windows, and several other operating systems use '.' as a path element to represent a directory one level above the current file/directory. Without proper input control and authorization, sensitive files/folders of the system can be accessed by entering paths pointing to these files/folders.

5. Types of attacks: Command Injection, Code Injection, Query Injection

[Web servers often use parameters in the URI as input to execute system commands and database queries. However, the data received in the request cannot always be trusted. An attacker can create and modify components in the request (such as methods, fields in the header, body.), to execute system commands, query the database.

For example, SQL Injection is a common attack in which the web server receives parameters in the URI that are part of the SQL query. Therefore, an attacker can trick the web server to execute illegal SQL queries, in order to steal or sabotage the database.
In general, data submitted by users should not be used directly to perform operations on the server. These data need to go through filters, which define what is valid and what is invalid, thereby eliminating unwanted data.

6. Revealing personal information

Clients often contain a lot of personal information, including information provided by the user to interact with the server (such as username, password, location, email address, etc.) and information about web browsing activities. of the user (history, bookmarks, etc.). When implementing, attention should be paid to preventing points that can reveal this private information.

7. Revealing sensitive information in the URI

URIs, by design, are meant to be shared with all users, and are not guaranteed to be secure. URIs are often displayed in the website's source code, and are stored in bookmarks without protection mechanisms. Therefore, it will be unsafe if the URI contains sensitive information, personal information, etc.

Avoid using the GET method to send personal information to the server, as it will be displayed in the URI. Use the POST method instead.

8. Revealing software information used

 The User-Agent, Via, Server fields in the header usually provide information about the software used by the sender. In theory, that allows attackers to more easily exploit known vulnerabilities in these software.