HTTP Desync: The Redux and Evolution of HTTP Smuggling and Splitting Attack Techniques
A special thanks to Adam Chaudry for his contribution to this blog.
A Brief History of HTTP Boundary-Based Attacks
Anyone familiar with modern telecommunications understands the fundamental importance of HTTP as the foundation for information exchange across the World Wide Web. HTTP supports the implementation of client-server connections that underpin web browsing and communication via HTTP messages. This includes HTTP requests configured and sent from a client to request data/resources from a server, as well as HTTP responses from a server back to the client with requested items or a status message.
However, throughout the early 2000s, vulnerabilities were identified within HTTP infrastructure, opening the door for a set of related attack patterns/techniques against HTTP agents. Such attacks include HTTP request splitting, HTTP response splitting, HTTP request smuggling, and HTTP response smuggling.
These attacks exploit message parsing vulnerabilities against HTTP agents running HTTP/1.0/1.1, by manipulating HTTP messages (request and/or response) to interfere with the HTTP agents’ interpretation of HTTP messages. This results in unauthorized and malicious HTTP messages being secretly sent and received to allow attacks such as cross-site scripting (XSS), cache poisoning, authentication bypass, content spoofing, resource location spoofing, session hijacking, and more.
The revelation of these attack techniques was made known to the Information Technology and Information Security communities in the early 2000s by various whitepapers and reports, such as the 2004 Sanctum Inc. Whitepaper Divide and Conquer and the 2005 Watchfire whitepaper HTTP Request Smuggling. These types of attack plagued the security of HTTP web applications for years, with relevant CVEs still being released to this day.
Although there has been a concerted effort to evolve the HTTP protocol to address the weaknesses behind these attacks, many HTTP agents are still not RFC complaint. This resulted in the configuration of HTTP infrastructure to accommodate varied HTTP agents, causing parsing discrepancies to exist in network paths interpreting HTTP messages. These discrepancies have continued allowing HTTP Smuggling and Splitting to take place.
Terminology Confusion of HTTP Request/Response Splitting/Smuggling
Despite being very commonplace in web-based attacks, there has been a lot of confusion about HTTP smuggling and splitting in the lexicon of IT security professionals. Many misunderstand the differences among these four attack techniques and often use the terms interchangeably. Additionally, most of the material pertaining to these attacks reference outdated sources from over 10 years ago and don’t incorporate the evolutions of the attacks.
James Kettle, Director of Research at PortSwigger, brought this topic back into the limelight with HTTP Desync Attacks: Request Smuggling Reborn, where he elaborates on new attack vectors and variants tied to HTTP request smuggling. Kettle uses the term “HTTP Desync” to describe this evolution of HTTP smuggling but does not explicitly define the term. For the CAPEC/CWE projects, we are defining HTTP Desync as “the 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.”
CAPEC Redux of HTTP Desync Entries
Kettle’s publication inspired the CAPEC Content Team to review and reevaluate four relevant CAPEC entries. It was determined, after extensive research, that significant improvements were needed to properly differentiate these attacks. We considered combining the two Splitting CAPEC entries and the two Smuggling entries, but the nuanced differences between the four entries indicated that all four should be retained but fully re-written to make those differences clear.
Also, it is important to note the difference between HTTP splitting and HTTP smuggling, since HTTP smuggling evolved from previous HTTP splitting patterns which are commonly remediated against. HTTP splitting is defined by Amit Klein as “the act of forcing a sender of (HTTP) messages to emit data stream consisting of more messages than the sender’s intension…the messages sent are 100% valid and RFC compliant.” Klein goes on to define HTTP Smuggling as “the act of forcing a sender of (HTTP) messages to emit [a] data stream which may be parsed as a different set of messages (i.e. dislocated message boundaries) than the sender’s intention…this is done by virtue of forcing the sender to emit non-standard messages which can be interpreted in more than one way.”
Ultimately, HTTP splitting is solely dependent upon the embedding/injection of special characters and character encoding within HTTP headers and web/browser object parameters. In contrast, HTTP smuggling does not, and it simply depends upon discrepancies in the interpretation of various HTTP headers.
The Updated Entries
Check out the new CAPECs here:
- HTTP Request Smuggling (CAPEC-33)
2. HTTP Response Smuggling (CAPEC-273)
3. HTTP Request Splitting (CAPEC-105)
4. HTTP Response Splitting (CAPEC-34)
Our next step will be to make appropriate changes to CWE to better characterize the weaknesses that enable these four attacks to be conducted.
