Re: [WEB SECURITY] Can HTTP Request Smuggling be blocked by Web Application Firewalls?

[Daniel <deeper () gmail com>]

Amit,

Maybe i've missed a point here, but why would you deploy a WAF behind
a web server and proxy server? in fact why would you even deploy the
WAF in this scenario?

Have you tested the 2nd scenario with a NC and two devices?


On 6/21/05, Amit Klein (AKsecurity) <aksecurity () hotpop com> wrote:
> 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
>
>
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/