anyways, i suppose these questions can be responded to in any way; maybe
I *am* just trolling.
(but what else can I do while waiting for a Mac to reboot?)

ciao ;^P

--
 | |\  /\ ---------------------------------------*

\/ |/  \/ Johns Hopkins University * Baltimore, MD

However, the scripts are very badly written, which he acknowledges, and
he is not maintaining them.  As a result, many of them contain security
holes that have been known for years, and many general bugs.

The result: lots of people download the scripts and need help fixing
the same bugs over and over again, and lots of others don't even know
the bugs are there.

Many people in this newsgroup have complained about this, and there is
presently a project underway (see http://www.*-*-*.com/
threads in this newsgroup with {*filter*}and UN{*filter*}in the Subject:) to
replace Matt's scripts in the affections of CGI novices with solid code.

The greatest risk, though, comes from the fact that the vast majority of
people downloading and implementing these scripts have no programming
knowledge of their own and, as such, are 'blissfully' ignorant of the
security risks, Y2K bugs, and the frequent total lack of proper error
handling.

The risk multiples when these novices decide to begin learning to program
by example based upon the way these scripts were written.  Pretty soon we
wind up with a lot more novice programmers writing free scripts for
distribution to the general public which contain the exact same bugs.

Some of the key issues to watch out for though:

1) Always included proper error-handling in your script.  This is
especially important when receiving input from users as you can never
really predict what they will supply you.  If the error occurs in a
critical section of the script, at least make sure the script will abort
as cleanly as possible.

2) Always perform taint/bounds checking on data, particularly that
supplied by a user or their browser.

3) Avoid passing user/forms supplied data to the command line (exec,
system, open pipe, backticks, etc) wherever possible.  If you must pass
the data to the command line, test it very carefully to make certain it
only contains valid options and that no undesirable characters or options
can be passed (not every visitor is going to be your friend, some will be
up to no-good).

4) Always check to make certain that an open on a file succeeded and/or
the creation of a new file or directory succeeded.

5) Always look at your scripts from the angle of a user who will be up to
no-good.  Rest assured, any weakness you can find in your script they can
too.  What happens if the user uploads too much data?  Not enough data?
The wrong data?  Bad data?  If there is login type security, do you
reauthenticate the user at every step or are you assuming they are valid
once they get past the login screen - assumptions can be dangerous.
Realize that if your script is sufficiently complex that there will likely
be bugs -- be proactive in tracking them down and repairing them

6) Study and come to understand what the security risks are.  Some risks
are unavoidable, others can be largely avoided with the proper
precautions.  Avoid making assumptions about your security -- test it.
Learn that obfuscation only complicates matters for a malicious party, it
does not offer a true defense.

7) There are many more you will learn with experience, these are just a
few that come to mind in the few minutes I had to write this (your choice
of programming language(s) will also play a role in the issues you need to
be aware of).

Bear in mind however that whilst Matt Wright may be the most exalted
in the Script Kiddie pantheon he _is_not_the_only_one_ - *any* program
found on the web must be treated with suspicion - particularly in the
realm of CGI. Of course there are certain unreproachable sources
which should be obvious.

I would suggest that if you are really uncertain of the provenance of some
piece of 'scripting' that you found on the net and are unable to determine
its suitability for its intended purpose then you should post the URL - the
URL mind not the whole code - to the most appropriate newsgroup for the
program in question.  I should be borne in mind however that - certainly
here - people won't be keen on offering support or debugging for these
programs but will we be very keen to point out the shortcomings in this
code - occasionaly some bored, hyperactive or just plain kind soul might
rewrite the thing so it will work properly ( an hey I have a disk full
of {*filter*}Perl programs awaiting a rewrite ... ).  

Just tell 'em I sent you ;-}