CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')

Description

The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret malformed HTTP requests or responses in ways that are consistent with how the messages will be processed by those entities that are at the ultimate destination.

HTTP requests or responses ("messages") can be malformed or unexpected in ways that cause web servers or clients to interpret the messages in different ways than intermediary HTTP agents such as load balancers, reverse proxies, web caching proxies, application firewalls, etc. For example, an adversary may be able to add duplicate or different header fields that a client or server might interpret as one set of messages, whereas the intermediary might interpret the same sequence of bytes as a different set of messages. For example, discrepancies can arise in how to handle duplicate headers like two Transfer-encoding (TE) or two Content-length (CL), or the malicious HTTP message will have different headers for TE and CL. The inconsistent parsing and interpretation of messages can allow the adversary to "smuggle" a message to the client/server without the intermediary being aware of it. This weakness is usually the result of the usage of outdated or incompatible HTTP protocol versions in the HTTP agents.

Potential Impact

Integrity, Non-Repudiation, Access Control

Unexpected State, Hide Activities, Bypass Protection Mechanism

Demonstrative Examples

In the following example, a malformed HTTP request is sent to a website that includes a proxy server and a web server with the intent of poisoning the cache to associate one webpage with another malicious webpage.

Attack

POST http://www.website.com/foobar.html HTTP/1.1
		 Host: www.website.com
		 Connection: Keep-Alive
		 Content-Type: application/x-www-form-urlencoded
		 Content-Length: 0
		 Content-Length: 54
		 
                 GET /poison.html HTTP/1.1
		 Host: www.website.com
		 Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
		 Host: www.website.com
		 Connection: Keep-Alive

When this request is sent to the proxy server, the proxy server parses the first four lines of the POST request and encounters the two "Content-Length" headers. The proxy server ignores the first header, so it assumes the request has a body of length 54 bytes. Therefore, it treats the data in the next three lines that contain exactly 54 bytes as the first request's body:

Result

GET /poison.html HTTP/1.1
		Host: www.website.com
		Bla:

The proxy then parses the remaining bytes, which it treats as the client's second request:

Attack

GET http://www.website.com/page_to_poison.html HTTP/1.1
		Host: www.website.com
		Connection: Keep-Alive

The original request is forwarded by the proxy server to the web server. Unlike the proxy, the web server uses the first "Content-Length" header and considers that the first POST request has no body.

Attack

POST http://www.website.com/foobar.html HTTP/1.1
		Host: www.website.com
		Connection: Keep-Alive
		Content-Type: application/x-www-form-urlencoded
		Content-Length: 0
		Content-Length: 54 (ignored by server)

Because the web server has assumed the original POST request was length 0, it parses the second request that follows, i.e. for GET /poison.html:

Attack

GET /poison.html HTTP/1.1
		Host: www.website.com
		Bla: GET http://www.website.com/page_to_poison.html HTTP/1.1
		Host: www.website.com
		Connection: Keep-Alive

Note that the "Bla:" header is treated as a regular header, so it is not parsed as a separate GET request.

The requests the web server sees are "POST /foobar.html" and "GET /poison.html", so it sends back two responses with the contents of the "foobar.html" page and the "poison.html" page, respectively. The proxy matches these responses to the two requests it thinks were sent by the client - "POST /foobar.html" and "GET /page_to_poison.html". If the response is cacheable, the proxy caches the contents of "poison.html" under the URL "page_to_poison.html", and the cache is poisoned! Any client requesting "page_to_poison.html" from the proxy would receive the "poison.html" page.

When a website includes both a proxy server and a web server, some protection against this type of attack can be achieved by installing a web application firewall, or using a web server that includes a stricter HTTP parsing procedure or make all webpages non-cacheable.

Additionally, if a web application includes a Java servlet for processing requests, the servlet can check for multiple "Content-Length" headers and if they are found the servlet can return an error response thereby preventing the poison page to be cached, as shown below.

Good

protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
				  
                    
                      
                      // Set up response writer object
                      ...try {
					  
						
                          // check for multiple content length headers
                          Enumeration contentLengthHeaders = request.getHeaders("Content-Length");
						  int count = 0;
						  while (contentLengthHeaders.hasMoreElements()) {
						  count++;
						  }
						  if (count > 1) {
						  
							// output error response
							}
							else {
							
							  
								// process request
							  
							  }
							  
                        
                    } catch (Exception ex) {...}
					}

In the following example, a malformed HTTP request is sent to a website that includes a web server with a firewall with the intent of bypassing the web server firewall to smuggle malicious code into the system.

Attack

POST /page.asp HTTP/1.1Host: www.website.comConnection: Keep-AliveContent-Length: 49223
                     zzz...zzz ["z" x 49152]POST /page.asp HTTP/1.0Connection: Keep-AliveContent-Length: 30
                     POST /page.asp HTTP/1.0Bla: POST /page.asp?cmd.exe HTTP/1.0Connection: Keep-Alive

When this request is sent to the web server, the first POST request has a content-length of 49,223 bytes, and the firewall treats the line with 49,152 copies of "z" and the lines with an additional lines with 71 bytes as its body (49,152+71=49,223). The firewall then continues to parse what it thinks is the second request starting with the line with the third POST request.

Note that there is no CRLF after the "Bla: " header so the POST in the line is parsed as the value of the "Bla:" header. Although the line contains the pattern identified with a worm ("cmd.exe"), it is not blocked, since it is considered part of a header value. Therefore, "cmd.exe" is smuggled through the firewall.

When the request is passed through the firewall the web server the first request is ignored because the web server does not find an expected "Content-Type: application/x-www-form-urlencoded" header, and starts parsing the second request.

This second request has a content-length of 30 bytes, which is exactly the length of the next two lines up to the space after the "Bla:" header. And unlike the firewall, the web server processes the final POST as a separate third request and the "cmd.exe" worm is smuggled through the firewall to the web server.

To avoid this attack a Web server firewall product must be used that is designed to prevent this type of attack.

The interpretation of HTTP responses can be manipulated if response headers include a space between the header name and colon, or if HTTP 1.1 headers are sent through a proxy configured for HTTP 1.0, allowing for HTTP response smuggling. This can be exploited in web browsers and other applications when used in combination with various proxy servers. For instance, the HTTP response interpreted by the front-end/client HTTP agent/entity - in this case the web browser - can interpret a single response from an adversary-compromised web server as being two responses from two different web sites. In the Example below, notice the extra space after the Content-Length and Set-Cookie headers.

Attack

HTTP/1.1 200 OK
		Date: Fri, 08 Aug 2016 08:12:31 GMT
		Server: Apache (Unix)
		Connection: Keep-Alive
		Content-Encoding: gzip
		Content-Type: text/html
		Content-Length : 2345
		Transfer-Encoding: chunked
		Set-Cookie : token="Malicious Code"
		
		<HTML> ... "Malicious Code"

Mitigations & Prevention

Implementation

Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].

Implementation

Use only SSL communication.

Implementation

Terminate the client session after each request.

System Configuration

Turn all pages to non-cacheable.

Detection Methods

Automated Static Analysis — Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then sea

Real-World CVE Examples

CVE ID	Description
CVE-2022-24766	SSL/TLS-capable proxy allows HTTP smuggling when used in tandem with HTTP/1.0 services, due to inconsistent interpretation and input sanitization of HTTP messages within the body of another message
CVE-2021-37147	Chain: caching proxy server has improper input validation (CWE-20) of headers, allowing HTTP response smuggling (CWE-444) using an "LF line ending"
CVE-2020-8287	Node.js platform allows request smuggling via two Transfer-Encoding headers
CVE-2006-6276	Web servers allow request smuggling via inconsistent HTTP headers.
CVE-2005-2088	HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header
CVE-2005-2089	HTTP server allows request smuggling with both a "Transfer-Encoding: chunked" header and a Content-Length header

Taxonomy Mappings

PLOVER: — HTTP Request Smuggling
WASC: 26 — HTTP Request Smuggling
WASC: 27 — HTTP Response Smuggling

Frequently Asked Questions

What is CWE-444?

CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product acts as an intermediary HTTP agent (such as a proxy or firewall) in the data flow between two entities such as a client and server, but it does not interpret mal...

How can CWE-444 be exploited?

Attackers can exploit CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')) to unexpected state, hide activities, bypass protection mechanism. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-444?

Key mitigations include: Use a web server that employs a strict HTTP parsing procedure, such as Apache [REF-433].

What is the severity of CWE-444?

CWE-444 is classified as a Base-level weakness (Medium abstraction). It has been observed in 6 real-world CVEs.

Description

Potential Impact

Integrity, Non-Repudiation, Access Control

Demonstrative Examples

Mitigations & Prevention

Detection Methods

Real-World CVE Examples

Related Weaknesses

CWE-436: Interpretation Conflict

Taxonomy Mappings

Frequently Asked Questions