CGI Security

The two biggest security holes are file i/o (reading from and writing to files) and sub-shells (where variables in the program can be interpreted as commands). The general way to avoid security holes is the same:

What to look out for

• File I/O File i/o means reading from and writing to files on the server. If file i/o is done improperly, the web-client can read or destroy files other than the ones you intended them to. The Perl commands related to file i/o (roughly in their relative level of danger) are:
  • open (">", "<", ">>" also see the sub-shell discussion below for "|")
  • unlink/rmdir
  • read (also the <FILEHANDLE> construct)
  • dbmopen (and the use of the associative array created)
  • print/printf/sprintf
  • write
  • close/dbmclose

  ---

• Sub-shells One of the great abilities of Unix is to run other programs in the middle of one of your programs. This can be quite dangerous if you don't look out. Ways of spawning sub-shells in Perl include: (these are pretty much equally dangerous)
  • eval
  • system
  • exec
  • `shell_command ` (backquotes)
  • open(HANDLE,"shell_ command|"); or open(HANDLE,"|shell_command");

How to make scripts more secure

• General Rule: Make the user-returned information fit your expectations Just because you have a form to access your CGI script doesn't mean that your script will always be called from that script; especially if someone's trying to use your script to do something bad. Don't do anything with an arbitrary set of variables
  • Make sure you know the specific variables your program uses. Don't do things like this:

    @user_args=split(/&/,$ENV{'QUERY_STRING'});
    foreach $file (@user_args) {
      open(FILE,">$file");
      print FILE "Hi there\n";
      close(FILE);
      }
    

  • Make the contents of your variables look like you expect them to
    • Use s/// and tr// liberally! Whenever possible, do something like this:

    read(STDIN,$buffer,$ENV{'CONTENT_LENGTH'});
    @pairs=split(/&/,$buff);
    foreach $pair (@pairs) {
      ($name,$value)=split(/=/,$pair);
      $value=~tr/+/ /;
      $value=~s/%([0-9A-Fa-f]{2})/pack("C",hex($1))/eg;
      ############# the next line is the important one ###############
      $value=~tr/A-Za-z0-9//cd;  #this wipes out anything non-alphanumeric
      $form{$name}=$value;
      }
    

    • Be even more specific if you can (like tr/0-9//cd; if you only want digits). If you do the alphanumeric-only tr, you don't need the 2 standard translation lines.

  ---

• Specific Guidelines for File I/O If your script has any file i/o, you want to make sure that any file description has no ~s or ../s in it, since those characters could be used to create or read from unexpected files. Do things like this:

      ## user-input in associative array %form
      $form{'filename'}=~tr/~//d;          #get rid of ~s
      $form{'filename'}=~s/\.\.\///g;      #get rid of ../s
      open(HANDLE,"$startpath/$form{'filename'}");
  

  ---

• Specific Guidelines for Sub-shells If your script spawns any sub-shells, you need to make sure it contains no shell metacharacters from user-input. Shell metacharacters are special characters used to separate, customize, or relate Unix shell commands. Shell metacharacters include (I doubt this is a comprehensive list):

      { } [ ] | ; < > & ( ) ! \
  

  Any user-supplied information which will be sent to a sub-shell should be run through something like this:

      $form{'search'}=~tr/A-Za-z0-9 ._=+-//cd;
      ## $form{'search'} is now clean but can still contain the characters we specify
      open(FIND,"grep $form{'search'} /export/home/me/mydatabase |");
  

  You can also do something a little less invasive than that by escaping those bad characters with a line like this:

      $form{'search'}=~s/([{}[]|\;<>()])/\\$1/g;
  

  This will put an escaping back-slash in front of any potentially dangerous character.

Return to:

Introduction to CGI Programming with Perl

The Kitschen Sink