Http Request Smuggling CL.TE

Short Introduction to Request Smuggling

INTRODUCTION

HTTP Request Smuggling (HRS) is a critical security exploit within the HTTP protocol, capitalizing on inconsistencies in how Content-Length and Transfer-Encoding headers are interpreted across various HTTP server implementations within an HTTP proxy server chain.

Understanding CL.TE based Request Smuggling

Most HTTP request smuggling vulnerabilities arise because the HTTP/1 specification provides two different ways to specify where a request ends: the Content-Length header and the Transfer-Encoding header. The Content-Length header is straightforward: it specifies the length of the message body in bytes. For example:

The Transfer-Encoding header can be used to specify that the message body uses chunked encoding. This means that the message body contains one or more chunks of data. Each chunk consists of the chunk size in bytes (expressed in hexadecimal), followed by a newline, followed by the chunk contents. The message is terminated with a chunk of size zero. For example:

In a CL.TE (Content-Length / Transfer-Encoding) HTTP request smuggling attack, the front-end server processes the Content-Length header while the back-end server interprets the Transfer-Encoding header. This discrepancy allows attackers to craft a malicious request where the Content-Length header indicates a specific length, but the Transfer-Encoding header suggests chunked encoding. Consequently, the front-end server may prematurely terminate the request based on the Content-Length, while the back-end server continues processing it as chunked.

This inconsistency can lead to security vulnerabilities, enabling attackers to inject and smuggle malicious content within the HTTP request, potentially bypassing security measures and gaining unauthorized access to sensitive resources.

DEMONSTRATION

To illustrate the exploitation of HTTP request smuggling using the CL.TE, we’ll perform a demonstration based on a PortSwigger lab.

1. Detection

In the web application, we’ll modify the HTML version to 1.1 and adjust the content length to 5 in the header. However, we’ll send a POST request to the root page with a body that contains 3 bytes, but also with a Transfer-Encoding Heade with value chunked.

In this scenario, the content length specified matchs, resulting in the frontend server to forward the request to the backend server. However, there is no valid chunk, the backend waits indefinitely for the bytes, eventually timing out. This observation confirms the presence of a Content-Length and Transfer-Encoding (CL.TE) confusion between the frontend and backend servers, indicating a probable HTTP Request Smuggling vulnerability.

2. Exploitation

To initiate a Request Smuggling attack by poisoning the incoming request, let’s begin by crafting a manipulated request.

In this scenario, the crafted request includes a legitimate request that prompts responses from both the frontend and backend servers. However, the smuggled request within the body remains in the buffer, potentially interfering with any subsequent valid requests sent afterward.

This is the manner in which the backend processes the smuggled request alongside the valid request, as the smuggled request is appended to the legitimate one.

Therefore, as the smuggled request is combined with the valid request, it leads to a 404 error being thrown. This demonstrates how HTTP Smuggling can be exploited.

REMEDIES

1. Ensure consistent parsing of requests for Content-Length and Transfer-Encoding headers.
2. Implement a WAF with tailored rules to detect and prevent HTTP smuggling attacks.

This was a concise explanation of HTTP request smuggling, focusing specifically on the TE.CL type vulnerability.