Overview

Guidelines

1. This service is only available to departments approved by AcIS management.

2. The new servers are available at http://www.columbia.edu and https://www1.columbia.edu. In addition, a test server is available at http[s]://wwwtest.cc.columbia.edu, and is generally (although not always) configured identically to the main pool of servers.

3. Infrastructure currently supports CGI and PHP based applications environments. This does not extend to support of the application itself if the application was not provided by AcIS.

4. For all projects, choose a unique short name consisting of alphanumeric characters, for example webfoo. A subproject name may also be selected where it makes sense, for example bar.

5. All applications must undergo a code review prior to installation. Generally, this code review will be performed by a member of the Unix Systems group. Code must be written securely. For guidelines, see documents such as
   • The World Wide Web Security FAQ
   • Various articles on securing PHP
   • Software Development Guide: Testing For Security Holes
   • Cross Site Scripting FAQ

   In cases where a group will be managing multiple or complicated applications, code review may be delegated to that group subsequent to approval by the Unix Systems Group.

6. CGI executables are installed in /www/cgi for the regular web servers and /wwws/cgi for the secure web servers. These directories are not writable from the web servers, executables should be installed from cunix, the toastmasters, or other appropriate hosts.

   Do not confuse the directory cgi for cgi-bin, which is the legacy directory.

   Sample installation paths:

   • /www/cgi/webfoo: A single executable for the regular server, available at http://www2.columbia.edu/cgi-bin/webfoo.
   • /www/cgi/webfoo/: An application directory for the regular server.
   • /wwws/cgi/webfoo: A single executable for the secure server, available at https://www2.columbia.edu/sec-cgi-bin/webfoo.
   • /wwws/cgi/webfoo/bar: A subproject directory for the secure server.

   Important: Do not set the permissions on your CGI to be world executable if you rely on environment variables for authentication (ie: if you use $USER as controlled by .htaccess). This can be spoofed by a local user with access to the filesystem. Group execute permission is also discouraged.

7. PHP documents are installed in /www/php for the regular web servers and /wwws/php for the secure web servers. These directories are not writable from the web servers, documents should be installed from cunix or other appropriate hosts.

   Sample installation paths:

   • /www/php/webfoo/: An application directory for the regular server.
   • /wwws/php/webfoo/bar: A subproject directory for the secure server.

8. Applications that wish to write data files and that do not have large disk space requirements may write to /www/cgi-upload/appname/.

9. Logging data is strongly recommended for applications that execute write operations. Logging must be to the Unix Systems approved syslog facility, local1, or to another location approved by Unix Systems if appropriate (in which case timestamps and program identifiers are required).

   Logging should include the following data, in addition to whatever application specific data may be appropriate:

   1. Start and end of session (login, logout, etc), to local1.info
   2. Major operations (processing a user request, changing something about a user or session, etc), to local1.info
   3. Any sort of error (permission denied, operation failed, etc), to local1.err

   Here is a sample Perl syslogger:

       #!/usr/bin/perl
   
       use Sys::Syslog;
   
       my $ident = 'webfoo';
   
       openlog($ident, 'pid', 'local1');
       syslog('info', 'db initialized');
       syslog('debug', "$nrecs records read from $infilnam");
       syslog('err', "can't open file $infilnam because %m");
       closelog();
       

   Logfiles are available for review at /www/cgi-log/appname. Applications that cannot use syslog must write their logfiles to this location.

10. Authentication of users may be obtained using the supported techniques.

    Note that the new web servers use a different mechanism for authenticating users. While existing .htaccess files should not require modification, developers should verify the expected access restrictions are still in place when moving old applications to the new servers.

    Important: The new web servers do not currently support unauthenticated POST operations to restricted resources (for example, where a form on a publically accessible page posts to a restricted CGI). Users must be authenticated before they may POST data to restricted resources.

11. The web server is configured to not follow symlinks in the cgi directory.

12. Versions of Perl prior to 5.6.1 are not supported.

13. Contact information must be included at the top of script files, or for compiled executables in an accompanying README. For compiled executables, the location of the source code and build instructions must be included with the contact information.

    It is strongly recommended that information on testing the application or a pointer to such information be included for use during future upgrades.

$Revision: 1.3 $