[WEB SECURITY] Re: Can HTTP Request Smuggling be blocked by Web Application Firewalls?
Andrew van der Stock
vanderaj at greebo.net
Wed Jun 22 02:17:43 EDT 2005
I feel that the WAF in this case would increase the likelihood of a
HTTP smuggling attack as it participates in the flow, and more than
likely interprets HTTP requests differently than pretty much
everything else out there. If they RST'd dodgy connections and left
alone all others, then maybe these devices serve a purpose, but if
it's a re-writing proxy, it has to affect the flow.
<rant = on>
I have been struggling with the point of "security" HTTP proxies
recently in several of the projects I've been involved with. The
projects were infected by sales people who say "Buy this widget, and
all your security problems are over". Nothing could be further from
the truth. I recently lost a battle to remove a virus scanning web
proxy on a private leased line which transmitted XML provided by MQ
Series. The impetus to buy useless things to solve non-existent
problems is troubling.
In my view, unless a proxy understands the underlying data and pages,
or XML DTDs if it is looking at SOAP requests, I feel the additional
burden of the proxies is rarely worthwhile and just adds one more
component which may be abused.
Security vendors should perform strict conformance testing and make
those results available to potential customers. Something like the
old IPsec and cache bake offs or industry certification that these
devices are truly RFC compliant would be nice.
On 22/06/2005, at 6:24 AM, Amit Klein (AKsecurity) wrote:
> Yesterday, NetContinuum announced
> 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