DECS CGI Scripting Policy and Instructions

  1. Read about and be aware of the security concerns regarding CGIs
  2. CGI scripts written in perl, must use 'Taint' perl

    #!/opt/bin/perl -T instead of #!/opt/bin/perl

    This minimizes security problems by not allowing the program to use unchecked user input (external environment variables) in system calls. It requires more work to untaint a variable through pattern matching, but information on how to do so can be found in the the WWW Security FAQ (question 45). Taint perl also requires you set your path at the beginning of the script: $ENV[PATH] = "/usr/bin"

  3. Your CGI programs must be put in your CGI directory

    This is a subdirectory in your web direcory (~/web/cgi-bin). Scripts should have a .cgi extension and can be accessed by using the following URL structure: ~username/cgi-bin/script.cgi
    Also, make sure that your scripts are not world-accessable while they are still in an unfinished or testing stage. Only after you are sure that your script it working correctly, should you open it up for public use. During testing do the following: chmod -R 750 ~/web/cgi-bin

    To give world access once your scripts have been thorougly tested: chmod -R 755 ~/web/cgi-bin

  4. Do NOT use the nph-test-cgi script or any other script that echo variables without quoting them.

    Doing so allows web clients to gain unauthorized access to files, and will result in the loss of your CGI priveledges. For example...
    DO echo QUERY_STRING = "$QUERY_STRING" DON'T echo QUERY_STRING = $QUERY_STRING

  5. Server-Side includes

    On our server, Server-side includes are enabled. However the #exec option has been disabled. Therefore you will not be able to include CGI output in the following manner: <!--#exec cgi=... --> or <!--#exec cmd=... -->
    You may still use include options such as: <!--#include file=... --> and <!--#include virtual=... --> Please be aware that parsing .shtml files places extra load on the web server, so Server-Side includes should be used in moderation.

  6. If you don't understand it, don't use it

    Do not use other's scripts unless you understand what they do. What appears to be harmless could contain maliscious routines buried within the code.

  7. CGI usage is a privilege

    Realize that this is a privilege. Abuse, misuse, or security compromises regarding this priviledge will result in its removal.

Note: These regulations may seem tedious, but CGIs pose a serious security problem. Since nothing is 100% secure (besides disconnecting ourselves from the internet), we are trying to take as many precautions as possible. If security is not accounted for, the system may be vandalized, which may include your own account.

Proceed to the request