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
