The Secure CGI environment is Integration's answer to the customer's demands to be able to write cgi-scripts freely, without being subject to the existing review process. An environment was created which met the following condition:

Rules and Regulations

All CGI MUST meet the following criteria:

• NO compiled binaries are to be uploaded
• All CGI Programs should be written in Perl.
• The first two lines must contain

  #!/usr/local/bin/perl
  alarm(300);
  

• No perl based chat rooms, search engines or Bulletin Boards.
  These tend to kill a system very quickly.
  

Why the environment is secure?

The environment can be considered secure because of the following:

• The web server is configured so that all files which live outside of the /infinet/www/CUSTOMER directory structure, are invisible to it.
• All file utilities and user shells such as sh,tcsh,bash,rm,mv,cp,cat... have not been installed in the CGI environment.
• The Webserver will throttle rouge CGI processes by "Sandboxing" the programs execution. CGI programs run as individual, unique processes, this can result in problems when a CGI script is badly written or receives data different to that it was expecting. In these cases a CGI can claim excessive amounts of system resources. If the server machine is spending most of it's time processing CGI programs its HTTP performance will suffer. The situation is compounded with a large number of virtual servers, where a single virtual server could be responsible for ninety percent of CGI usage. CGI Sandboxing allows limits to be placed on the amount of resources a virtual servers CGI programs can consume.

  CGI Sandboxing resource restrictions depend on the implementation of the ulimit system call within the operating system.

FAQ (Frequently asked Questions)

Q: Who do I contact to get my own environment?

Your point of contact for installing CGI environments is the Affiliate Help Service Web Page.

Q: Who do I contact if I cannot get my program to work

• You or your developer should thoroughly test the script locally before installing them at InfiNet.

• Make sure the 1st two lines contain
  • #! /usr/local/bin/perl
  • alarm(300);
    

• Check your servers error log.

• If you have tried all of the above and cannot get your script to work and you are sure it works on other systems, please visit the Affiliate Help Service Web Page to have your script reviewed.

Q: How do I upload a perl script to my environment?

• All content is updated by direct FTP to your CGI environment.

• Upload your script to the cgi-bin directory

• Issue the quote command to make the program executable.
  NOTE: FTP clients, by default, upload files without the executable flag set.
  ftp> quote
  (command line to send) site chmod 775 scriptname.pl
  250 Changed.
  ftp>
  Where scriptname.pl is the name of the script you upload.
  

• The script is now active on the server. It can be viewed at http://yourdomain.com/cgi-bin/script.pl

Q: What commands/Perl Modules are available to me?

Software installed, and supported libraries

• Perl Modules an versions can be found here.
• sendmail - /usr/lib/sendmail
• perl - /usr/local/bin/perl
• pgp - /usr/local/bin/pgp
• mail - /usr/bin/mail

Q: How can I make my script secure from hackers?
To avoid problems that might compromise your site's security or availability, we have developed a short list of basic requirements for CGI programs.

• In place of using system, exec, or eval, use an open statement as in this example:

  open (MAIL,"| /usr/lib/sendmail -t -oi") || die "Failed to open sendmail: $!";
  
  print MAIL "To: $MAILTO{ To }\n";
  print MAIL "From: $MAILTO{ From }\n";
  print MAIL "Subject: $MAILTO{ Subject }\n\n\n";
  
  &dumpdata();  # Output any text here 
                # as the body of the message..
    
  close (MAIL);
  

• Do not use backtick operands

• When accepting user input from a CGI program and then using the user input in a call to the system in any way, always check for the following characters ";", "<", ">", "&", "*", "`", "|", "$", "/", ".", and "#". If any of these characters are found in the string, don't continue. The following example shows how you can check for these characters:

  if ( $USERINPUT =~ /[;<>*`|&$\/\.#]/ ) {
  print "<h1>ERROR: Invalid characters found in user
  field</h1>"; 
  } else {
  # proceed normally
  }
  

• Another often missed item is the nul character '\0'. This should be stripped out of any user input. It can be used to trick programs into opening files you don't want opened. Simple solution:

  $insecure_data=~s/\0//g; 	## Remove them

• For e-mail address forms make sure the username/domain name combination being entered by the user is safe. The following example shows how this can be accomplished:

  unless ($USERINPUT =~ /^[\w@\.\-]+$/ {
  print "<h1>ERROR: Invalid characters found in e-mail
  address</h1>"; 
  } else {
  # proceed normally
  }
  

• If you open system files from within your Perl script there are precautions you must take. If the file you are opening is based on some user input, be careful. The user could use the ".." or some multiple use of "/" or "//" directory path to move around your system and open other files. Always check your data when using anything obtained from end users. It could contain tainted data which can include something your not expecting and cause unexpected results in your script or in the chrooted environment. Alaways validate your input and strip out unwanted characters like "." "/".

• When referencing your CGI-BIN directory within your HTML code always use a relative reference as follows:

  ex. <FORM METHOD="POST" ACTION="./cgi-bin/script.pl">
  

Q: What scripts are available from InfiNet?

• InfiNet has pre installed 3 commonly used "canned" CGI scripts into your CGI environment. Each will requier some basic configuration. Documentation for customization can be found in the comments of each script.
  • Email cgi-bin/email.pl
  • Counter cgi-bin/counter.pl
  • Jump Menu cgi-bin/jump.pl