HTTP Request Smuggling Detections

by Brian Joe on September 2, 2019

I’m excited to announce the ability of Signal Sciences to detect HTTP Request Smuggling attempts! For customers implementing modern, multi-tiered or cloud native web applications, Signal Sciences can now seamlessly detect and mitigate HTTP Request Smuggling attempts which seek to take advantage of some of the inherent limitations of the HTTP Standard. This detection has been deployed to all customers as a new hop headers system signal and can be easily activated from the Signal Sciences management console or via an API. With a few clicks, customers can get instant visibility into whether their web application is seeing any potential HTTP Request Smuggling attempts and take actions to mitigate those requests.

What is HTTP Request Smuggling?

“HTTP Request Smuggling is an attack technique that abuses the discrepancy in parsing of non RFC compliant HTTP requests between two HTTP devices (typically a front-end proxy or HTTP-enabled firewall and a back-end web server) to smuggle a request to the second device “through” the first device. (WASC 2010)

When there are one or more HTTP backend servers (such as a CDN and Origin server, a very common architectural pattern), a gray area in the HTTP standard can cause each server to parse and interpret the same set of HTTP requests with a specific set of HTTP Headers in two different ways. The whitespace between the two interpretations is where attackers can “smuggle” in malicious code or requests. This vulnerability was explained in more detail over at the Portswigger website.

The key HTTP Header fields (Content-length and Transfer-encoding) that are at conflict both involve the serialization of data and can each independently be used to identify the start of one request and the start of another. Thus there is room for misinterpretation by different web servers.

HTTP Smuggling can be innocuous in and of itself, but can lead to vulnerabilities ranging from medium to critical depending on what attack the HTTP Smuggling facilitates. Take for example cache poisoning – A legitimate request is sent to an application and a smuggled request’s response is then cached for the initial legitimate request. A simple attack would involve defacing a commonly trafficked part of the application like the “/about” page with possibly some image the attacker uploaded to “/profile/hacker.jpg”. For clients receiving cached content for the “/about” page they might actually get the profile pic of the attacker instead.

Sponsorships Available

Why is HTTP Request Smuggling Significant?

This attack type affects request traffic using the HTTP/1.1 standard, and is also only effective when there are multiple tiers of web-servers (such as proxies, or CDNs). This is very concerning because popular architectures like cloud native and microservices are especially susceptible to this type of attack. HTTP smuggling can also be chained into other higher impact exploit scenarios and it affects many tier 1 CDN providers, some of whom (and some of their customers) are identified specifically in the Portswigger disclosure.

Signal Sciences makes it easy for customers to protect their applications from smuggling attempts

We put our customers first when designing our response to the vulnerability. As much as possible, we wanted to focus on making life easier for our customers by Not blocking any of their legitimate users, surfacing visibility about when this exploit was being attempted, and Empowering them with configurable controls to mitigate these types of attacks. We felt that these principles would give customers the best experience and protection possible.

As a result of this customer focused approach, we designed our solution with a holistic solution:

First, we look for HTTP requests with both Transfer-Encoding and Content-Length headers by inspecting the HTTP request.
We then remove malformed Content-Length and Transfer-Encoding headers, with minimal impact to non-hostile end users. By automatically removing malformed headers, customers get instant protection with close to zero false positives, which could negatively impact legitimate users.
Next, we generate a signal when requests where malformed headers are present, providing visibility and insights into these types of attacks.
Lastly, we provide customers with the ability to create rules based on the appearance of this signal using our Power Rules features.

A Word from Remitly

by Bob Aman, Principal Security Engineer, Remitly

On August 12th, a security researcher made us aware of a request smuggling vulnerability in our application. Remitly employs a micro-service architecture and use a number of load balancers and proxies to route traffic to the correct destination, with Signal Sciences serving as our web application firewall. Because traffic passes through multiple reverse proxy layers in our stack, with some of these layers processing HTTP requests in slightly different ways, request desynchronization was a possibility. We notified Signal Sciences of the discovery of this issue, and they responded immediately, beginning to develop a mitigation and detection for this class of vulnerability. Deployment was a simple matter of turning on a configuration switch.

We’d like to thank alex_vel, Felipe Bird, and an anonymous researcher, who independently discovered and reported the vulnerability to us, as well as everyone at Signal Sciences who worked tirelessly to ship a mitigation so quickly.

Conclusion

HTTP Request Smuggling is a significant vulnerability that all developers and security teams should be aware of given the prevalence of multi-tiered proxy architectures in modern applications. For those looking for a solution, Signal Sciences can help! Contact us to schedule a demo today!