CWE

Common Weakness Enumeration

A Community-Developed List of Software Weakness Types

CWE/SANS Top 25 Most Dangerous Software Errors
Home > CWE List > CWE- Individual Dictionary Definition (3.0)  
ID

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

Weakness ID: 444
Abstraction: Base
Structure: Simple
Status: Incomplete
Presentation Filter:
+ Description
When malformed or abnormal HTTP requests are interpreted by one or more entities in the data flow between the user and the web server, such as a proxy or firewall, they can be interpreted inconsistently, allowing the attacker to "smuggle" a request to one device without the other device being aware of it.
+ Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

+ Relevant to the view "Research Concepts" (CWE-1000)
NatureTypeIDName
ChildOfBaseBase436Interpretation Conflict
+ Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (CWE-1003)
NatureTypeIDName
ChildOfBaseBase436Interpretation Conflict
+ Relevant to the view "Development Concepts" (CWE-699)
NatureTypeIDName
MemberOfCategoryCategory442Web Problems
+ Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

PhaseNote
Architecture and Design
Implementation
+ Applicable Platforms
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

(Language-Independent classes): (Undetermined Prevalence)

+ Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

ScopeImpactLikelihood
Integrity
Non-Repudiation
Access Control

Technical Impact: Unexpected State; Hide Activities; Bypass Protection Mechanism

An attacker could create a request to exploit a number of weaknesses including 1) the request can trick the web server to associate a URL with another URLs webpage and caching the contents of the webpage (web cache poisoning attack), 2) the request can be structured to bypass the firewall protection mechanisms and gain unauthorized access to a web application, and 3) the request can invoke a script or a page that returns client credentials (similar to a Cross Site Scripting attack).
+ Demonstrative Examples

Example 1

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: 44

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 POST request in the first seven lines, and encounters the two "Content-Length" headers. The proxy server ignores the first header, so it assumes the request has a body of length 44 bytes. Therefore, it treats the data in the next three lines that contain exactly 44 bytes as the first request's body. The proxy then parses the last three lines which it treats as the client's second request.

The 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, and the second request is the line with the first GET (note that the second GET is parsed by the web server as the value of the "Bla" header).

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 use 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)
Example Language: Java 
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) {...}

}

Example 2

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.1
Host: www.website.com
Connection: Keep-Alive
Content-Length: 49223

zzz...zzz ["z" x 49152]
POST /page.asp HTTP/1.0
Connection: Keep-Alive
Content-Length: 30

POST /page.asp HTTP/1.0
Bla: POST /page.asp?cmd.exe HTTP/1.0
Connection: 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.

+ Observed Examples
ReferenceDescription
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
Web servers allow request smuggling via inconsistent Transfer-Encoding and Content-Length headers.
+ Potential Mitigations

Phase: Implementation

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

Phase: Implementation

Use only SSL communication.

Phase: Implementation

Terminate the client session after each request.

Phase: System Configuration

Turn all pages to non-cacheable.
+ Memberships
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
NatureTypeIDName
MemberOfViewView884CWE Cross-section
MemberOfCategoryCategory990SFP Secondary Cluster: Tainted Input to Command
+ Notes

Theoretical

Request smuggling can be performed due to a multiple interpretation error, where the target is an intermediary or monitor, via a consistency manipulation (Transfer-Encoding and Content-Length headers).
+ Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVERHTTP Request Smuggling
WASC26HTTP Request Smuggling
+ References
[REF-433] Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin. "HTTP Request Smuggling". <http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf>.
+ Content History
Submissions
Submission DateSubmitterOrganizationSource
PLOVER
Modifications
Modification DateModifierOrganizationSource
2008-07-01Eric DalciCigital
updated Potential_Mitigations, Time_of_Introduction
2008-09-08CWE Content TeamMITRE
updated Name, Relationships, Other_Notes, Taxonomy_Mappings
2009-05-27CWE Content TeamMITRE
updated Name, Related_Attack_Patterns
2010-02-16CWE Content TeamMITRE
updated Taxonomy_Mappings
2011-06-01CWE Content TeamMITRE
updated Common_Consequences
2012-05-11CWE Content TeamMITRE
updated Common_Consequences, Relationships
2012-10-30CWE Content TeamMITRE
updated Demonstrative_Examples, Potential_Mitigations
2014-06-23CWE Content TeamMITRE
updated Other_Notes, Potential_Mitigations, Theoretical_Notes
2014-07-30CWE Content TeamMITRE
updated Relationships
2015-12-07CWE Content TeamMITRE
updated Relationships
2017-11-08CWE Content TeamMITRE
updated Applicable_Platforms
Previous Entry Names
Change DatePrevious Entry Name
2008-04-11HTTP Request Smuggling
2008-09-09Interpretation Conflict in Web Traffic (aka 'HTTP Request Smuggling')
2009-05-27Inconsistent Interpretation of HTTP Requests (aka 'HTTP Request Smuggling')

More information is available — Please select a different filter.
Page Last Updated: November 14, 2017