Re: CGI scripts in sh

[Mark Rafn <dagon () DAGON NET>]

[not sure this kind of general question is on topic or not, but it's
close.  If you disagree, Mr. Moderator, feel free to reject this message.]

On Thu, 21 Sep 2000, Crypteria wrote:

> I got a question concerning CGI scripts, i've been told that sh
> scripts are way more insecure than perl or c/c++ scripts.

Never accept statements like this at face value - always ask for
specifics.  In this case, there are some reasons to be extra careful with
shell scripting.

> I find great to use the power of shell scripting and the ability to
> use commands in scripts and I just wondered why they could be more
> insecure ?

Primarily because it's so easy (and necessary) to use external system
commands in scripts, and each one is interpreted by the shell before the
external program gets it.  You introduce any vulnerabity these external
commands have into your CGI.  It's also tricky to wash user-data to make
it safe for use on a command line.

> After all, a good shell scripts can be flawless just as a bad perl
> script can be dangerous...

Absolutely.  But it's much harder to write a good shell script than good
perl.  Specifically, it's a lot easier in Perl to avoid sending user data
to dangerous or not-fully-understood external programs.  There are three
main reasons Perl is better here:

1) more builtins with mostly-understandable semantics.  The language
itself makes it easy to do a lot of things directly from the code, without
the extra step of constructing and parsing a shell command line.  C/C++
has this advantage as well, for some tasks.

2) Taint mode.  This is HUGE.  Perl tells you when you're letting
user-supplied data into an unsafe operation.  It's not perfect
(especially if you just untaint stuff without understanding why you have
to), but it's a giant step up.

3) String handling.  Perl makes it possible to analyze user input and
clean or reject input that has illegal characters or other errors BEFORE
sending it to any external program.  In a shell, you often can't, or must
jump through many quoting hoops.
--
Mark Rafn    dagon () dagon net    <http://www.dagon.net/>