[WEB SECURITY] Can HTTP Request Smuggling be blocked by Web Application Firewalls?
Amit Klein (AKsecurity)
aksecurity at hotpop.com
Tue Jun 21 16:24:23 EDT 2005
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).
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity