SECURITY IN GENERAL

There is no such thing as a "secure system".  The moment your systems
administrator decides to provide any services to the users of your system,
is the moment your system becomes insecure.  

Programs will always have bugs and security holes and the management of
security is always an ongoing battle.

Like any service provided by your system, web services present security
problems.  SSI, Authentication, Web Document Retrieval, CGI, Servelets,
Modules, Server APIs, and all the rest of the services which can be
provided by your web server may open a myriad of obscure, but serious
holes. 

Of course, we all know that the whole point of having a web server is to
provide services.  If you close off all contact with the outside world,
what good is a networked computer at all.  

Thus, one must accept the dangers inherent in web services, but take
the
responsibility to do whatever one can to mitigate those dangers.

Your responsibility as a programmer and user of a shared system is to
make sure that you make your code as secure as possible.

Doing so means that you have the responsibility to:

1. Notify your systems administrator when you install an application.
   Provide her with the source code if she requests it.

2. Make sure keep track of bug reports and security announcements for any
   application you install.  That means notifying the author of the
   application that you have installed it.

3. Keep up to date on security issues in general.  There are many FAQs,
   books, and USENET/Web forums related to Web Security.  Get familiar
   with them.

4. Follow all the instructions related to security that are included with 
   the applications.

5. Ask for help and advice on how to make your site more secure.

6. Report all suspect bugs or security holes to the authors of the
   program.

7. Examine access and error logs for attempted hacks.  If you see
   something even remotely suspicious, report it to your systems
   administrator.

8. Make regular backups.

	
		    SECURITY ISSUES FOR THIS SCRIPT

Here are a list of issues you should understand before making this script
available to the public.

1. Any directory containing code, setup information, data, or libraries
   should contain an index.html file so that a user can not get a raw
   directory listing.

2. All file names should be changed from the default names in the
   distribution, to your own names.  

   For example, a file like default.setup should be changed to something
   like myScript.setup.txt.  Make the new name as unguessable as possible.

   Remember, other people can download the distribution file as well.  If
   you do not change the filenames, they can easily download your
   administrative files (such as password files, setup files, or data
   files).

   For further security, use the .cgi extension for important files.  The
   .cgi extension will tell the web server not to simply display the file,
   but to run it as a CGI script.  Sensitive files (password, data or
   setup files) will return a 500 Server Error if treated as a CGI script 
   which will deter the hacker.

3. Better yet, move all files except for executables, out of the web
   document tree altogether so that there is no possible way a user could 
   access them using their web browser. 

   This is why we have put all the relevant file paths in the setup files.
   It should be easy to move them all by simply changing their path
   location in the setup file.  This is the best option.

4. Make sure that no file is writable unless it MUST be writable for the
   program to work.  For example, a setup file should not be writable
   (chmod 444) because the application will never need to write to it.
   However, a data file will need to be writable (chmod 666).  

   Similarly, do not allow write access to directories which contain files
   that do not require write access.  If there are files which require
   write access, try to keep them all in a specific directory.  Do not
   include any non-write access files in that directory.  

5. Tell your systems administrator to revoke CGI privileges for any
   directory which contains files that MUST have write access.

6. Check with your systems administrator to see if SSI has been enabled on
   your web site.  If so, disable all dynamically generated HTML output.
   In most scripts you will find a variable like $allow_html which can be
   used for this disabling.  Also, see if your systems administrator can
   disable SSI in your CGI directories.

7. Do not modify these application files to include any system calls and
   do not modify executables such that user-defined data can be passed to
   the shell.

8. Keep up to date with security by registering this script with
   register@extropia.com and by visiting www.extropia.com regularly for
   security and bug announcements.