HTTP Request Smuggling Attacks
A new research has identified four new variants of HTTP request smuggling attacks that work against various commercial off-the-shelf web servers and HTTP proxy servers.

What is HTTP Request Smuggling?

HTTP request smuggling (or HTTP Desyncing) is a technique employed to interfere with the way a website processes sequences of HTTP requests that are received from one or more users.
Vulnerabilities related to HTTP request smuggling typically arise when the front-end (a load balancer or proxy) and the back-end servers interpret the boundary of an HTTP request differently, thereby allowing a bad actor to send (or “smuggle”) an ambiguous request that gets prepended to the next legitimate user request.

This desynchronization of requests can be exploited to hijack credentials, inject responses to users, and even steal data from a victim’s request and exfiltrate the information to an attacker-controlled server.

What’s in New variants?

The new variants using various proxy-server combinations, including Aprelium’s Abyss, Microsoft IIS, Apache, and Tomcat in the web-server mode, and Nginx, Squid, HAProxy, Caddy, and Traefik in the HTTP proxy mode.

The list of all new four new variants is as below, including an old one that the researcher successfully exploited in his experiments.
Variant 1: “Header SP/CR junk: …”
Variant 2 – “Wait for It”
Variant 3 – HTTP/1.2 to bypass mod_security-like defense
Variant 4 – a plain solution
Variant 5 – “CR header”

When handling HTTP requests containing two Content-Length header fields, Abyss, for example, was found to accept the second header as valid, whereas Squid used the first Content-Length header, thus leading the two servers to interpret the requests differently and achieve request smuggling.

In situations where Abyss gets an HTTP request with a body whose length is less than the specified Content-Length value, it waits for 30 seconds to fulfill the request, but not before ignoring the remaining body of the request.

This also results in discrepancies between Squid and Abyss, with the latter interpreting portions of the outbound HTTP request as a second request.

A third variant of the attack uses HTTP/1.2 to circumvent WAF defense as defined in OWASP ModSecurity Core Rule Set (CRS) for preventing HTTP request smuggling attacks craft a malicious payload that triggers the behavior.

Lastly,using the “Content-Type: text/plain” header field was sufficient to bypass paranoia level checks 1 and 2 specified in CRS and yield an HTTP Request Smuggling vulnerability.

What Are the Possible Defenses?

After the findings were disclosed to Aprelium, Squid, and OWASP CRS, the issues were fixed in Abyss X1 v2.14, Squid versions 4.12, and 5.0.3 and CRS v3.3.0.

Calling for normalization of outbound HTTP Requests from proxy servers,the need for an open source, robust web application firewall solution that’s capable of handling HTTP Request Smuggling attacks.