> Is this a reasonable path to go down, or is there more functionality in
vendor responses to and protection
> against SQL injection?

The best (and cheapest) way to address this issue is to implement proper
input handling in your web apps. Even if it's a third-party's code, you
should work with them to fix as many of these vulnerabilities as possible.

Depending on what systems you have sitting out in front of your web apps and
how sophisticated you can get with content rules, there are some general
ways to prevent SQL injection attacks. They almost all rely on a similar
subset of characters in order to open or close the injection attack. The
biggest headache is building filters around all of the possible encoding
options for these characters. For example:

' is the same as %27 is the same as ' to the web server, but they're
very different in-path.

I guess the bottom line is that if you have to choose one, fix the app. If
you can do both, do both. And if you can only secure your web apps with
in-line proxies and IPS rules, then set the expectation with your business
that they're going to get pwned again.


firewall-wizards mailing list