HTTP Request Smuggling – The Ultimate Guide
Published: 2022-06-23 09:09:17

An HTTP request smuggling attack is when the hacker interferes with the processing of HTTP requests between clients and web servers. The attackers maliciously customize and craft multiple HTTP requests from a single request, making two target entities see the same HTTP request as distinct, separate requests.

The impacts of HTTP request smuggling attacks are far-reaching since the hacker can perform [session hijacking](https://crashtest-security.com/session-hijacking-prevention/) or **bypass security controls** for unauthorized access to sensitive data. This article describes the causes of HTTP request smuggling, its prevention, and mitigation techniques.

## What is an HTTP Request?

When clients want to access a resource on an application server, they send an HTTP request. The HTTP request is made using a Uniform Resource Locator (URL). A sufficient HTTP request majorly contains the below three things:

* A **request line** – The request line contains an **HTTP request method,** the **request URL’s path component,** and an **HTTP version number**. The HTTP request method instructs the server about the desired action on the resource. There are various HTTP request methods like **GET, POST, PUT,** etc. The request URL’s path component refers to the resource target and points to the backend connections for the requested resource. Finally, the HTTP version indicates the expected version while sending the response back.

* An **HTTP request header** – The HTTP header provides a receiver with details about the request context. Some commonly used request headers are Accept, Authorization, Content-type, etc.

* A **message body** – The message body/request body includes the actual content of the request and varies depending on the HTTP method used.

## What is HTTP Request Smuggling?

HTTP request smuggling attacks are web application attacks that **exploit the inconsistencies** in processing the request body by front-end and backend servers. If the HTTP request is not compliant with RFC-specified best practices, attackers can use the request and make two target end-users see two different sets of request messages.

HTTP requests are sent one after the other, from the front-end server to the backend server over the same network. Requests are parsed based on the HTTP headers and processed accordingly at the backend server. HTTP request smuggling attacks are usually carried out where the front-end and back-end servers **do not agree** on the **boundaries of the request** or other details of the **HTTP protocol implementation**. If parsing limits are not set, an attacker can maliciously modify the HTTP requests by including another request within its message body. The backend server then interprets the attacker’s additional request as the next request, interfering with how the server processes subsequent requests.

## HTTP Smuggling Vulnerabilities

HTTP request smuggling vulnerabilities arise from the fact that the HTTP protocol provides two ways to specify the boundary of a request:

* **Content-Length (CL)** header-  This figure denotes the length of the HTTP request’s message body in bytes.

* **Transfer-Encoding (TE)** header- A hop-by-hop header divides the request body into non-overlapping ‘chunks’ sent independently. A chunk of size zero terminates the message.

An HTTP message can contain **both headers,** which brings up a conflict in boundary configuration. Vulnerabilities born out of this conflict are:

* **CL.TE Vulnerabilities**

The front-end server uses the Content-Length header while the backend relies on the Transfer-Encoding header. It is possible to craft a malicious request as per the below code:

```
POST / HTTP/1.1
Host: darwin-vulnerable-web.com
Content-Length: 12
Transfer-Encoding: chunked

0

SMUGGLED CODE
```

The front-end server processes the Content-Length header and acknowledges that the message body is 12 bytes long up to the boundary of *SMUGGLED CODE*. When the backend server receives this request, it processes based on the Transfer-Encoding header, which instructs it to interpret the message with chunked encoding. The first byte is stated to be zero-length, so the server terminates the request. This leaves the *SMUGGLED CODE* unprocessed, so the backend server treats this as the start of the next HTTP request in the sequence. 

* **TE.CL Vulnerabilities**

The front-end server uses the Transfer-Encoding header, while the backend relies on the Content-Length header. The hacker can then perform a request smuggling attack using malicious code similar to:

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Transfer-Encoding: chunked

6
SMUGGLED CODE
0
```

The front-end treats the message body as using chunked encoding. It processes the first chunk size as  6 bytes long until the line after *SMUGGLED CODE*. The backend server then receives and interprets the request as 4 bytes long, up to the start of the line after 6. The remaining bytes starting with *SMUGGLED CODE* are not processed, so the server treats them as the start of the next incoming HTTP request.

* **TE.TE vulnerabilities**

Both servers use the Transfer-Encoding header, but attackers can induce one of the servers not to process the request by obscuring it. Some ways to obfuscate the Transfer-Encoding header are shown below: 

```
Transfer-Encoding: xchunked
Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked
Transfer-Encoding
: chunked
```

The attacker specifies an obfuscated transfer-encoding header so that the back or front end is induced not to interpret it. The hackers then proceed with an attack similar to those explained in CL.TE and TE.CL vulnerabilities.

## How to Prevent HTTP Request Smuggling Attacks

Some ways to prevent HTTP request smuggling attacks include:

### Prioritize Transfer-Encoding over Content-Length Headers

If the request contains TE and CL headers, the server should be configured to prioritize the transfer encoding header over content length. **TE headers** can **cover static** and **dynamic requests,** so using them for requests with two headers is the first line of defense against CL.TE and TE.CL attacks.

### Use the Latest HTTP Protocol

Use **HTTP/2** in all deployments as it comes with a **robust, built-in** mechanism to evaluate the length of HTTP requests. If HTTP/2 is used both in the front-end and backend servers, it provides an innate immunity to request smuggling.

### Secure Logged HTTP Traffic

Ensure that HTTP logs are only accessible to **administrative users**. This restricts attackers from accessing unintended parts of the HTTP requests, making it difficult to insert a malicious request into a legitimate user request.

### Reject Requests with Doubleheaders

Any request that contains TE.CL, CL.TE and TE.TE headers should get an **HTTP 400** error response. This error informs the client that the server will not process the HTTP request due to malformed request syntax. This enforces the **consistent interpretation** of **HTTP headers** in both the front-end server and backend server.

### Use a Vulnerability Scanner

[Vulnerability scanners](https://crashtest-security.com/vulnerability-scanner/) can identify poorly configured HTTP requests and help mitigate attacks before they occur. The **Crashtest Security Suite** includes an automated security vulnerability scanner that enforces continuous testing to reduce the risk of attacks on web applications. Continuous testing helps QA and security teams to identify TE.CL, CL.TE and TE.TE vulnerabilities before attackers can leverage them for attacks.

## Types of HTTP Request Smuggling Attacks

Examples of HTTP request smuggling attacks include:

### Bypassing Client Authentication

During authentication, the client uses a “common name (CN)” to verify the legitimacy of the server responding to their requests. The authentication component passes relevant certificate details to the backend in an HTTP header. The front-end server appends a header containing the CN to incoming requests as below:

```
GET /admin HTTP/1.1
Host: darwin-web.com
X-SSL-CLIENT-CN: darwin
```

Users typically hide these headers, so the backend implicitly trusts the details provided. HTTP request smuggling type of attack involves **sending** specific **malicious headers** and **values,** using which attackers can **bypass security controls**. By configuring the front-end servers to overwrite these headers, hackers usually hide the smuggled requests from the front end so that they reach the backend unaltered. A sample code is shown below:

```
POST /darwin HTTP/1.1
Host: darwin-vulnerable-web.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
X-SSL-CLIENT-CN: darwin
Header: value
```

### Exploiting Reflected XSS Using HTTP Request Smuggling

HTTP request smuggling **simplifies** [Reflected XSS exploits](https://crashtest-security.com/reflected-cross-site-scripting/) since it does not require interaction with legitimate users. The attacker only needs to create a smuggled request with the XSS payload, which will be processed with the next application user’s request. Assuming an application is found to contain the Reflected XSS vulnerability in the Running-Time header, the attacker can craft an HTTP request smuggling attack as follows:

```
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 63
Transfer-Encoding: chunked

0

GET / HTTP/1.1
Running-Time: <script>alert(1)</script>
Header: Value
```

### Capturing Other User Requests

Attackers can use HTTP request smuggling to **access** the details of authorized users’ requests in applications that allow for the storage and retrieval of textual data. The components extracted include session **tokens, cookies,** and other **sensitive data** submitted by the client. The attacker creates a smuggled request to submit data to the storage function, with the data parameter being at the bottom of the request. The backend appends the subsequent legitimate request with the smuggled request, resulting in successful processing and storage of the smuggled request. The attackers can then retrieve this stored data using the normal retrieval function.

## Mitigating HTTP Request Smuggling Vulnerabilities

Some measures to mitigate HTTP smuggling include:

* Use a web **application firewall** to **block** the malicious URL and IP addresses

* Normalize abnormal requests, and **close** the **TCP connection** for persistent ambiguous requests

* **Disable** any **performance optimizations** that use the Content-Length and Transfer-Encoding header in the backend server

* Avoid using a **Content Distribution Network** or **reverse proxy server** whenever possible

With an HTTP smuggling vulnerability, the impacts of a successful attack are critical. Attackers can gain access to user accounts and sensitive information. Protect your web application and data assets by trying the [Crashtest Security Suite](https://crashtest-security.com/).

*This article has already been published on https://crashtest-security.com/http-request-smuggling/ and has been authorized by Crashtest Security for a republish.*