[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
> (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

The Web Security Mailing List Archives

More information about the websecurity mailing list