WebApp Sec: Can HTTP Request Smuggling be blocked by Web Application Firewalls?

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

Yesterday, NetContinuum announced 
(http://www.netcontinuum.com/newsroom/pressReleaseItem.cfm?uid=52) that their NC-1000 
Application Security Gateway protects against HTTP Request Smuggling.

I find this weird. The essence of HTTP Request Smuggling 
(http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf) is that two HTTP-aware 
devices (e.g. web server and cache/proxy server) interpret the data stream differently. 
Now, as long as the attack is aimed at two such devices BEHIND the WAF (Web Application 
Firewall, and this analysis pertains to WAFs at large, not just NC-1000), then the WAF 
stands a chance of blocking the attack by making sure the HTTP is 100% kosher (which is a 
problem in itself, e.g. exploiting the IIS/5.0 48KB bug is arguably consisting of kosher 
HTTP, see p. 5/7).

BUT, when the two devices attacked are IN FRONT of the WAF, then the WAF stands very little 
chance of blocking the attack, because it's already late in the game.

Even if the attack is aimed at one device in front of the WAF, and one behind the WAF, it's 
not trivial for the WAF to block the attack. In some cases, the first device changes the 
HTTP stream such that it's impossible to tell that the attack took place. This is the case 
with Apache proxy and the Chunked-Encoding vs. Content-Length (p. 12/14). In this case, 
Apache takes an HTTP request with both Transfer-Encoding: Chunked and Content-Length: 0, 
assembles the body from the chunks, and eliminates the Transfer-Encoding header, resulting 
in a fully RFC-compliant HTTP stream.
Even if traces of the attack remain after the first device (e.g. multiple Content-Length 
headers, p.10/12), the WAF must drop the HTTP request altogether. It is NOT sufficient to 
modify it into a valid HTTP request (e.g. by erasing one of the Content-Length headers), 
because it may then choose the "wrong" HTTP header, and in itself facilitate the attack (or 
at least not block it).

-Amit