HTTP Desync attacks: A variant of request smuggling attacks

In August 2019, the PortSwigger team released an update to HTTP request smuggling attacks – HTTP Desync attacks. In their research, they identified the significant damage that smuggling attacks could do and showed how a once-ignored technique could be used to cause massive damage.

Request smuggling attacks exploit the server’s inability to safely handle anomalies in various aspects of an HTTP request. Examples of an HTTP request smuggle range from deviating from the standard usage of CR (Carriage Return) and LF (Line Feed) characters in a request or using standard headers like Content-Length and Transfer-Encoding headers maliciously. This underlying vulnerability can also be exploited for XSS (cross-site scripting) attacks, unauthenticated access to privileged information, and cache poisoning.

The typical way cybercriminals execute these attacks is by sending the Content-Length and Transfer-Encoding headers in the same request. According to the RFC specifications, this combination should be treated by prioritizing the Transfer-Encoding header’s value. However, the trick is to camouflage the “Transfer-Encoding” header by introducing non-ASCII characters in the name so the HTTP parser ignores the header.

An example of such an attack is shown here:

POST / HTTP/1.1
Host: saas-app.com
Content-Length: 4
Transfer-Encoding : \x00chunked

1234<script>alert("xss")</script>GET / HTTP/1.0

In the above example, there is a white space in the name “Transfer-Encoding” which was valid according to Golang’s HTTP library (Golang CVE-2019-16276) and allows the request to be considered valid, resulting in the smuggled request being executed by the backend application.

How to defend against HTTP Desync attacks

The defense against such an attack involves:

• Correctly identifying that a second HTTP request is being camouflaged and tunneled inside of another HTTP request


• Denying that second request access to the backend server

Multiple variants of Desync attacks exist today. The Barracuda WAF and WAF-as-a-Service can help you defend against all such Desync attacks. They identify these attacks right at the protocol validation stage and block illegal requests such as the ones seen above. This provides complete protection for your application against these attacks.

Some examples of the protections offered are:

• Requests with both a Transfer-Encoding and Content-Length header are considered request smuggling and dropped by default


• HTTP headers that do not follow the RFC 7230 grammar are considered malicious and blocked


• Blocking requests with multiple Content-Length headers by default


• Blocking requests with multiple decimal values in the Content-Length header [E.g.: “Content-Length: 42, 42”]


• Block requests with the CL header where length does not match the payload size

Barracuda Web Application Firewall (WAF) protects applications, APIs, and mobile application backends against a variety of attacks including the OWASP Top 10, zero-day threats, data leakage, and application-layer denial of service (DoS) attacks. Barracuda WAF and WAF-as-a-Service are part of Barracuda Cloud Application Protection (CAP), a platform that protects web applications wherever they reside — in the cloud, on-premises, or hybrid.

Gartner has named Barracuda a Challenger in the 2020 Gartner Magic Quadrant for Web Application Firewalls. This is the fourth year in a row that Barracuda has been recognized as a Challenger in this report based on ability to execute and completeness of vision. See everything Gartner is saying about web application security. Get the full report with all the actionable insights for protecting your business.

Get your complimentary copy now