Hey there,
When you analyze the I/O of even a heinously complex system, you can
identify the data entry points fairly easily and completely. Since you need
only protect input data (assuming no other security issues like directories
set to all public access etc...) it turns out to be a trivial task to scrub
the input statement for things like "%20cmd.exe%20..." as well as 'select'
or 'drop' or 'sp_' in either hex or regular char format. We've built some
pretty robust inpout checking for cold fusion code that seems to work, and
by using the same code over and over, we seem to build reliable data entry
modules.
Now that I've said this, the data gods will strike me with lightning, but
even in big shops (I've done a couple of 200+ developers jobs in 25 years)
it's standardization of specific items like this that tend to allow you to
focus on task, and not have to be the security expert every time. This is
not a soapbox for re-usable code per se - nor to squash creativity, but it
is more reliable to develop 12 or 15 input routines that scrub input and re
use them, than it is to reinvent the wheel every day.
Security appliances are good but imperfect. They have a place, for sure. If
your e-commerce form is generating data input by plunking down variables
that are supposedly generated by your own database of items, it is foolproof
to compare the input stream with what's expected, and to puke out the
unexpected. You have the ability to compare what 'should be' with 'what is'
; you know what you expect. You also know what you'd NEVER allow. That kind
of logic, once written is easy to standardize, and is much better than high
horsepower device that looks for stuff that's not related to your
application, and costs a ton of cash to buy and update. I'd rather put more
$$ into bandwidth and servers than appliances.
My .02
Marty Block
Kesem.net
-----Original Message-----
From: Matthieu Estrade [mailto:mestrade@apache.org]
Sent: Thursday, February 17, 2005 4:57 PM
To: webappsec@securityfocus.com
Subject: Re: ISA Server and SQL Injection
Bogdan Tomchuk wrote:
Protection against this kind of injection is just other way of patching
the code, so useless, because this assume knowing difference between
"good" and "bad" URL, so for OWA, for example, you define list of
templates for all known "good" URL and anything else will be consider
as SQL injection. I do not understand why to spend money on expensive
firewall staff if you can patch or upgrade software.
Sure, if the patch is available. (A webapp firewall is a protection against
way to exploit a web app vulnerability, not against some identified
vulnerable application only). So patching is not the only solution. if it
was, explain me why so many system are vulnerable to worm that exploit old
vuln, and today, some worm are still doing so much disaster.
Now tell me how you protect a web app developped by an internal team, a
custom web app. Which patch are you waiting and from who ??? i am not sure
each company do automatic and permanent web vulnerability assessment.
Keep your software current is always better then "imaginable" security
given by software level firewall especially against SQL injection.
In a perfect world, maybe... You should say this to big companies with
security team, they are all dumb and do not understand security. they should
not use firewall but only windows update program or apt-get dist upgrade ;)
Do you know the life of a vulnerability ? many times, the vuln stay private,
then public and then vendors do patch. How long between the private and the
patch ?? sometimes few days, sometimes years... So you stay vuln during all
this time because you are "up to date !!!"
Many big companies separate the team doing security, the one doing web dev,
the one maintaining the network etc... All these team are not synchronized
on what happen in each other.
When the security team is not in contact with the app guy and they are in
charge of security. What are they doing ? they install some web app firewall
to prevent attack.
