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 or bypass security controls for unauthorized access to sensitive data. This article describes the causes of HTTP request smuggling, its prevention, and mitigation techniques.
Don’t have time to read? Listen to this blog post instead.
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:
1. 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.
2. 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.
3. 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:
1. Content-Length (CL) header- This figure denotes the length of the HTTP request’s message body in bytes
2. 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:
1. 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 CODEThe 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.
2. 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
0The 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.
3. 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
: chunkedThe 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 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: darwinUsers 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: valueExploiting Reflected XSS Using HTTP Request Smuggling
HTTP request smuggling simplifies Reflected XSS exploits 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: ValueCapturing 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:
1. Use a web application firewall to block the malicious URL and IP addresses
2. Normalize abnormal requests, and close the TCP connection for persistent ambiguous requests
3. Disable any performance optimizations that use the Content-Length and Transfer-Encoding header in the backend server
4. 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.
This article has already been published on https://crashtest-security.com/http-request-smuggling/ and has been authorized by Crashtest Security for a republish.
