CAPEC-33: HTTP Request Smuggling
Also known as: HTTP Desync
An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages using various HTTP headers, request-line and body parameters as well as message sizes (denoted by the end of message signaled by a given HTTP header) by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to secretly send unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server). See CanPrecede relationships for possible consequences.
Last updated
Overview
A maliciously crafted HTTP request, which contains a second secretly embedded HTTP request is interpreted by an intermediary web proxy as single benign HTTP request, is forwarded to a back-end server, that interprets and parses the HTTP request as two authorized benign HTTP requests bypassing security controls. This attack usually involves the misuse of the HTTP headers: Content-Length and Transfer-Encoding. These abuses are discussed in RFC 2616 #4.4.3 and section #4.2 and are related to ordering and precedence of these headers. [REF-38] Additionally this attack can be performed through modification and/or fuzzing of parameters composing the request-line of HTTP messages. This attack is usually the result of the usage of outdated or incompatible HTTP protocol versions in the HTTP agents. This differs from CAPEC-273 HTTP Response Smuggling, which is usually an attempt to compromise a client agent (e.g., web browser) by sending malicious content in HTTP responses from back-end HTTP infrastructure. HTTP Request Smuggling is an attempt to compromise a back-end HTTP agent via HTTP Request messages. HTTP Splitting (CAPEC-105 and CAPEC-34) is different from HTTP Smuggling due to the fact that during implementation of asynchronous requests, HTTP Splitting requires the embedding/injection of arbitrary HTML headers and content through user input into browser cookies or Ajax web/browser object parameters like XMLHttpRequest.
How the attack works
The phases an attacker typically follows to carry out this attack.
- Step 1Explore
[Survey network to identify target] The adversary performs network reconnaissance by monitoring relevant traffic to identify the network path and parsing of the HTTP messages with the goal of identifying potential targets.
- Scan networks to fingerprint HTTP infrastructure and monitor HTTP traffic to identify HTTP network path with a tool such as a Network Protocol Analyzer.
- Step 1Experiment
[Identify vulnerabilities in targeted HTTP infrastructure and technologies] The adversary sends a variety of benign/ambiguous HTTP requests to observe responses from HTTP infrastructure in order to identify differences/discrepancies in the interpretation and parsing of HTTP requests by examining supported HTTP protocol versions, message sizes, and HTTP headers.
- Step 2Experiment
[Cause differential HTTP responses by experimenting with identified HTTP Request vulnerabilities] The adversary sends maliciously crafted HTTP requests to interfere with the parsing of intermediary and back-end HTTP infrastructure, followed by normal/benign HTTP request from the adversary or a random user. The intended consequences of the malicious HTTP requests will be observed in the HTTP infrastructure response to the normal/benign HTTP request to confirm applicability of identified vulnerabilities in the adversary's plan of attack.
- Continue the monitoring of HTTP traffic.
- Follow an unrecognized (sometimes a RFC compliant) HTTP header with a subsequent HTTP request to potentially cause the HTTP request to be ignored and interpreted as part of the preceding HTTP request.
- Step 1Exploit
[Perform HTTP Request Smuggling attack] Using knowledge discovered in the experiment section above, smuggle a message to cause one of the consequences.
- Leverage techniques identified in the Experiment Phase.
What the attacker needs
Prerequisites
- An additional intermediary HTTP agent such as an application firewall or a web caching proxy between the adversary and the second agent such as a web server, that sends multiple HTTP messages over same network connection.
- Differences in the way the two HTTP agents parse and interpret HTTP requests and its headers.
- HTTP agents running on HTTP/1.1 that allow for Keep Alive mode, Pipelined queries, and Chunked queries and responses.
Skills required
- Medium skill: Detailed knowledge on HTTP protocol: request and response messages structure and usage of specific headers.
- Medium skill: Detailed knowledge on how specific HTTP agents receive, send, process, interpret, and parse a variety of HTTP messages and headers.
- Medium skill: Possess knowledge on the exact details in the discrepancies between several targeted HTTP agents in path of an HTTP message in parsing its message structure and individual headers.
Resources required
- Tools capable of crafting malicious HTTP messages and monitoring HTTP message responses.
Consequences
What a successful CAPEC-33 attack can achieve.
Execute Unauthorized Commands
Affects: Confidentiality, Integrity, Availability
Gain Privileges
Affects: Confidentiality, Access Control, Authorization
Modify Data
Affects: Integrity
How to mitigate it
Defenses that reduce the risk of CAPEC-33.
- Design: evaluate HTTP agents prior to deployment for parsing/interpretation discrepancies.
- Configuration: front-end HTTP agents notice ambiguous requests.
- Configuration: back-end HTTP agents reject ambiguous requests and close the network connection.
- Configuration: Disable reuse of back-end connections.
- Configuration: Use HTTP/2 for back-end connections.
- Configuration: Use the same web server software for front-end and back-end server.
- Implementation: Utilize a Web Application Firewall (WAF) that has built-in mitigation to detect abnormal requests/responses.
- Configuration: Prioritize Transfer-Encoding header over Content-Length, whenever an HTTP message contains both.
- Configuration: Disallow HTTP messages with both Transfer-Encoding and Content-Length or Double Content-Length Headers.
- Configuration: Disallow Malformed/Invalid Transfer-Encoding Headers used in obfuscation, such as: Headers with no space before the value “chunked” Headers with extra spaces Headers beginning with trailing characters Headers providing a value “chunk” instead of “chunked” (the server normalizes this as chunked encoding) Headers with multiple spaces before the value “chunked” Headers with quoted values (whether single or double quotations) Headers with CRLF characters before the value “chunked” Values with invalid characters
- Configuration: Install latest vendor security patches available for both intermediary and back-end HTTP infrastructure (i.e. proxies and web servers)
- Configuration: Ensure that HTTP infrastructure in the chain or network path utilize a strict uniform parsing process.
- Implementation: Utilize intermediary HTTP infrastructure capable of filtering and/or sanitizing user-input.
How to detect it
Indicators that this attack may be underway.
- Differences in requests processed by the two agents. This requires careful monitoring or a capable log analysis tool.
Examples
When using Haproxy 1.5.3 version as front-end proxy server with with Node.js version 14.13.1 or 12.19.0 as the back-end web server it is possible to use two same header fields for example: two Transfer-Encoding, Transfer-Encoding: chunked and Transfer-Encoding: chunked-false, to bypass Haproxy /flag URI restriction and receive the Haproxy flag value, since Node.js identifies the first header but ignores the second header. See also: CVE-2020-8287
When using Sun Java System Web Proxy Server 3.x or 4.x in conjunction with Sun ONE/iPlanet 6.x, Sun Java System Application Server 7.x or 8.x, it is possible to bypass certain application firewall protections, hijack web sessions, perform Cross Site Scripting or poison the web proxy cache using HTTP Request Smuggling. Differences in the way HTTP requests are parsed by the Proxy Server and the Application Server enable malicious requests to be smuggled through to the Application Server, thereby exposing the Application Server to aforementioned attacks. See also: CVE-2006-6276
Apache server 2.0.45 and version before 1.3.34, when used as a proxy, easily lead to web cache poisoning and bypassing of application firewall restrictions because of non-standard HTTP behavior. Although the HTTP/1.1 specification clearly states that a request with both "Content-Length" and a "Transfer-Encoding: chunked" headers is invalid, vulnerable versions of Apache accept such requests and reassemble the ones with "Transfer-Encoding: chunked" header without replacing the existing "Content-Length" header or adding its own. This leads to HTTP Request Smuggling using a request with a chunked body and a header with "Content-Length: 0". See also: CVE-2005-2088
Terminology & mappings
Alternate terms
- HTTP Desync
- Modification/manipulation of HTTP message headers, request-line and body parameters to disrupt and interfere in the interpretation and parsing of HTTP message lengths/boundaries for consecutive HTTP messages by HTTP agents in a HTTP chain or network path.
Mapped taxonomies
- WASC: HTTP Request Smuggling (26)
Frequently asked questions
Common questions about CAPEC-33.
- What is CAPEC-33?
- An adversary abuses the flexibility and discrepancies in the parsing and interpretation of HTTP Request messages using various HTTP headers, request-line and body parameters as well as message sizes (denoted by the end of message signaled by a given HTTP header) by different intermediary HTTP agents (e.g., load balancer, reverse proxy, web caching proxies, application firewalls, etc.) to secretly send unauthorized and malicious HTTP requests to a back-end HTTP agent (e.g., web server). See CanPrecede relationships for possible consequences.
- How does a HTTP Request Smuggling attack work?
- It typically unfolds over 4 phases. It begins with: [Survey network to identify target] The adversary performs network reconnaissance by monitoring relevant traffic to identify the network path and parsing of the HTTP messages with the goal of identifying potential targets.
- How do you prevent CAPEC-33?
- Design: evaluate HTTP agents prior to deployment for parsing/interpretation discrepancies.
- What weaknesses does CAPEC-33 target?
- CAPEC-33 exploits 1 CWE weakness, including CWE-444 (Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')).
- How severe is CAPEC-33?
- MITRE rates CAPEC-33 as High severity with medium likelihood of attack.
References
Attack-pattern data is sourced from the MITRE CAPEC catalog (v3.9). Weakness associations link to the corresponding CWE entries on RadicalNotion.AI.
Defend against CAPEC-33
Track the CVEs and weaknesses attackers exploit with this technique, with AI-written analysis and remediation guidance.