quick server pages
   
Manual page for Security(issues)

Security issues




Setuid CGI executables

By definition, quisp applications are either read-write or read-only. If your application will be updating a database or files, it is read-write. If it doesn't need to update anything, it is read-only.

As a general policy most web servers invoke CGI programs using a fictitious user called nobody. This is done as a security precaution to limit the damage that can be done to other people's files by a malfunctioning program.

If your system will be read-only, you can probably get the desired results by allowing quisp to run as nobody. However, your project directories & files must all be world-readable, and your logs and tmp directories may need to be world writable. Your quisp CGI executable should be readable and executable by the world, but not setuid or setgid.

Another option for read-only is to create a dummy userid in the same group as the database owner, but that doesn't itself own any files. Then chmod the quisp CGI executable so that is setuid to the dummy userid, and setgid to the group (chmod 6755). Then, your project directories & files must be group readable, but not world readable.

If your system will be read-write, the quisp CGI executable will need permission to write to files. There are two options:

  • The best option is to make your quisp CGI executable setuid to a userid that can write to database or files (chmod 6755)
  • A second (very risky) option is to make your data files world-writable. This is too dangerous for all but the most casual uses; you must be willing to accept the fact that your data could be blown away at any time.

Let's assume you (wisely) choose the first option. It, too, has security issues that must be fully understood. CGI programs are world-accessible, and if a hacker is able to find a security hole in a CGI program and exploit it, and the CGI program is setuid to an identity that has write permission on important files, it is possible that the user could damage these files.

There are currently no known security problems with quisp, but undiscovered flaws are always possible.

Because of these concerns, some web hosts have restrictions on setuid with respect to CGI programs. Apache has a suEXEC module to help with this.

If your web host completely prohibits setuid CGI programs, you will not be able to use quisp to update a shsql database (or other files) on that host unless you opt for the very risky world-writable option.

You can see the userid and groupid that are in effect when your quisp CGI executable runs, by bringing up the testpage1 example included with the distribution. If you try the demo database application w/ data entry (art demo), it will tell you if database updates are possible or not.


CGI invocations of shell

CGI programs are world-accessible. The ability to invoke shell commands and capture the results is a powerful and flexible programming technique. However, if a CGI program takes user input (or CGI user variables) and uses these to build a shell command which it then executes, there is the potential for hackers to enter sequences of characters (especially shell metacharacters, quotes, and command terminators such as ;) that alter the shell command to do bad things.

The quisp #shell facility addresses this by automatically screening out a predefined list of shell metacharacters from all variables present in the shell command. Developers should fully understand this potential security hole and verify that metacharacter filtering is indeed working as they want it to, for their application.

Of course, if your application does not issue any shell commands, then this is not a concern.


Buffer overruns

QUISP utilizes CGIC 1.07 to fetch all CGI user variables.


Masking the debug switch

The _DEBUG user variable may be added to a URL at any time to print out system diagnostic information. If this shows information that you don't want the world to see, you can change the variable name to something obscure, using the config debugtag setting.


Other?

There may be other security issues that I am unaware of at the time of this writing.


quick server pages    
Copyright Steve Grubb    


Markup created by unroff 1.0,    April 14, 2004.