Re: web appliaction security products (AKA application firewalls)

[Bennett Todd <bet () rahul net>]

2002-11-22-13:24:32 Jason Childers:
> (5) Some tools require you to put them in "learning" mode so they
> can "understand/recognize" what normal usage of your site is.  In
> my view, that's not a WAF security product... that's a smarter
> IDS!

I'd like to expand on this thought a little bit.

A web proxy or other firewall component designed to improve security
of webservers at the application level has to have some way of
telling the difference between legitimate queries and attempts to
burgle the server, perhaps via exploiting bugs.

The tightest config you can get comes when you manually configure
the proxy to precisely define what are legal queries, with very
precise specifications for every one, including minimum/maximum
lengths, numeric scale ranges, exact parameter formats, allowed
alphabets, the whole schmeer. This requires duplicating the
front-end scanning process of your webserver, replicating its
specification in the config language of your application proxy. This
amounts to a security code review, which is a good thing. It's also
labor-intensive, some shops are unwilling to expend that labor.

For such shops, a popular alternative is to have a proxy that can
"train" to learn valid requests. The problem with this is that it's
impossible for training to really teach such a proxy some details,
e.g. the maximum permitted field lengths and permitted alphabets for
various fields. So proxies that are configured only by training
aren't going to be as strict as you can make a manually-configured
parameter-checking proxy.

> If your website changes, then you have to put the tool back in
> learning mode - thereby exposing your website's security and your
> infrastructure at known calculatable times.

This concern I'm not completely in agreement with, however. It
certainly applies in small "joe's bait shop and web hosting" type
places, but serious shops have an intermediate stage between
development and production, variously called quality assurance,
or testing, or beta, or some such. This stage includes automated
coverage testing, with automatic test suites that are carefully
designed and maintained alongside the code to exercise every bit
of it. If you're content with the weaker validity checking from
training-configured proxies, you can train the new config in the qa
pass, and push the updated config to the proxy servers along with
the site update as part of the production release.

-Bennett

Attachment: _bin
Description: