At 04:37 PM 09/18/2001 +0200, Grierson, Garry (UK07) wrote:
>The internal people that have been granted access to the servers running
>this system probably wouldn't have the knowledge or inclination to attempt a
>hack.
Well, lets get our terminology straight first :)
To "hack" is a good thing...lets not fall into the mass-media trap of
equating computer intrusion with "hacking".
That being said, nowadays you don't need much knowledge to compromise
security on a computer network. Thousands of pre-made "script kiddie"
exploit tools are available which make it trivial to sniff passwords, gain
root access, cause Denial of Service attacks, etc. etc. Even your
grandmother could do it.
As has been said before, "security through obscurity" is no security at
all. I apologize if I offend anyone by making a parallel to the terrorist
attacks in New York City, but it highlights an undeniable truth: Security
is compromised most effectively when the target least expects it.
> Only around eighty out of a possibly much higher number have been
>given access although it is intended that some external users may be given
>access to this system.
Your system and security model *must* be designed to take ANY "exception"
(i.e. "some external users") into account, no matter how infrequently these
exceptions may occur.
>Perhaps instead of describing what I have to work with my question should be
>more general:
>How do you ensure that Perl CGI scripts are safe from attack?
Nothing is safe from attack, but you can make them safer from compromise by
doing some of the following:
Always run your scripts with taint checking (-T) turned on, but *don't*
rely on -T alone to ensure input/output data security. Taint checking is
only effective if you write robust regexs to clean and check incoming data.
If you're interfacing with a database via CGI, DON'T directly use data
received from CGI input parameters to construct your SQL queries. SQL
queries should be treated in the same way that you would if you were
sending parameters to an external system call: Wring the parameters through
a GOOD regex and DBI's quote() function to ensure that you're sending
secure data with no funny-business hiding in them (i.e. shell escapes,
semicolons etc.).
Regarding regexs, instead of trying to filter out all possible forms of
"bad" data, its better to write the regex so it only ALLOWS specific data,
in the format that you specify. Otherwise, you will invariably fail/forget
to disallow something that you shouldnt be letting through.
My general rule is, you can't be too paranoid. Write your code from the
perspective of a potential attacker, and plug the obvious holes, and use
your creativity to figure out all the not-so-obvious holes that exist, and
plug them accordingly. Of course, you can't do this unless you know all of
the tricks of the trade that system crackers use, so studying exploit
scripts and having a subscription to the BUGTRAQ mailing list (or at least
a frequent browsing of the web archives) is a *requirement* for any
programmer or sysadmin who is interested in maintaining secure systems.
hope this helps...Aloha,
mel
--
mel matsuoka Hawaiian Image Productions
Chief Executive Alphageek (vox)1.808.531.5474
[EMAIL PROTECTED] (fax)1.808.526.4040
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
