CGI Script Security:

Now that you have secured your HTML Form by limiting the number of characters that a person or a robot ("Bad Guy") could enter into a single Form field, you will want to secure your CGI Script from a potential Internet attack.

CGI Scripts are commonly written in languages such as Perl, PHP and ASP. The specific syntax of these languages may be different, but the goal and function of these scripts are the same. This article will only discuss the concepts of what the Script needs to do, not the specific statements necessary to accomplish this.

The information that is sent from a Form to a processing Script is sent as a "data stream". This stream includes all of the variables and their contents packed into a continuous string of data. One of the jobs of the Script is to extract the expected information from this stream. These come in data pairs: variable name and content value.

The first thing that your Script will need to do, as it pulls out these data pairs, is to check each variable's contents for "funny characters" or unexpected characters. Commonly, the Bad Guys will try in insert command ending characters like ";", so they can then piggy back their commands onto commands being run in your Script. Another common character seen is the "`", or back quote, which is the initial character used to execute a system command, a way to get direct access to your web server computer. Typically a series of these special characters are checked for in a statement containing a "Regular Command" format and would look like: /[;><\*`\|]/. If one of these characters are found, an error condition will occur that your Script should handle, by generating a page letting the user of the Form know that they submitted a Form with fields containing bad data. The Script can be set up to be more restrictive of certain specific variables. For example, a field that should contain a user's e-mail address should not contain any "," or " " which may be used to stack a series of e-mail addresses into this field. If you are only expecting numeric, alphabetic or "specific text" values, the content of these variables can be restricted in this way.

The next thing you should consider setting up in the Script are limits of the length of each variable that is passed from the Form (I know you already did this in the Form, but this is necessary just to be sure that what you did is not being bypassed). Most fields should not exceed lengths of 50 characters, though I'm sure you can see how some fields can even be shorter. Form "TEXTAREA" or multiline input will need greater lengths to be permitted, possibly 500 characters (don't forget to mention this limit in your Form).

The next critical concept in Script security is that you do everything you can not to allow user input to be placed in any "system calling" command. In other words, if you can verify the contents of a variable and then make system calls using your own command statement contents, this would be the way to go.

If you are using "environmental variables" (eg: REMOTE_ADDR or HTTP_USER_AGENT), it is usually a good idea to copy the contents of these into your own variables BEFORE you extract data from the data stream. This is because the Bad Guys have realized that they can override the value of these variables when they feed their bad data streams to your Script. (Pretty sneaky huh?)

Keeping a log or generating alert e-mails will keep you on top of any unexpected use of your script (be sure to specify in your messages to yourself which script, directory, and account they are coming from).

Other Security Links (More Technical):

PHP:
PHP and the OWASP Top Ten Security Vulnerablities
PHP Security Mistakes
PHP Security, Part 1
On the Security of PHP, Part 1
Top 7 PHP Security Blunders [PHP & MySQL Tutorials]
A Note on Security in PHP

Perl:
O'Reilly Perl.com
Perl Security Tips
Perl Security">
Perl Tutorial part II
PERLSEC
Perl Security
Basic Perl Security | taint checking