.ig >>
<STYLE TYPE="text/css">
<!--
        A:link{text-decoration:none}
        A:visited{text-decoration:none}
        A:active{text-decoration:none}
        OL,UL,P,BODY,TD,TR,TH,FORM { font-family: arial,helvetica,sans-serif;; font-size:small; color: #333333; }

        H1 { font-size: x-large; font-family: arial,helvetica,sans-serif; }
        H2 { font-size: large; font-family: arial,helvetica,sans-serif; }
        H3 { font-size: medium; font-family: arial,helvetica,sans-serif; }
        H4 { font-size: small; font-family: arial,helvetica,sans-serif; }
-->
</STYLE>
<title>quisp: security issues</title>
<body bgcolor=99cc99 vlink=0000FF>
<br>
<br>
<center>
<table cellpadding=2 bgcolor=FFFFFF width=550 ><tr>
<td align=right><a href="quisp_home.html">
<img src="img/quisp2.gif" border=0><br><small>quick server pages</a> &nbsp; &nbsp; </td></tr>
<td>
.>>

.TH Security issues TDH "14-APR-2004   TDH scg@jax.org" 


.SH Security issues

.ig >>
<br><br><br>
.>>

.SH Setuid CGI executables
.LP
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.

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

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

.LP
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
(\fCchmod 6755\fR).  Then, your project directories & files must be group readable, 
but not world readable.

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

.IP \(bu
The best option is to make your quisp CGI executable \fBsetuid\fR to a 
userid that can write to database or files (\fCchmod 6755\fR)

.IP \(bu
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.

.LP
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.

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

.LP
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.

.LP
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.

.LP
You can see the userid and groupid that are in effect when your quisp CGI
executable runs, by bringing up the \fCtestpage1\fR 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.

.ig >>
<br><br><br>
.>>
.SH 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 \fC;\fR) that alter the shell command
to do bad things.
.LP
The quisp
.ig >>
<a href="shell.html">
.>>
\0#shell
.ig >>
</a>
.>>
facility addresses this by automatically screening out a 
.ig >>
<a href="shell.html">
.>>
\0predefined list
.ig >>
</a>
.>>
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.
.LP
Of course, if your application does not issue any shell commands, then this is not a concern.

.ig >>
<br><br><br>
.>>
.SH Buffer overruns
QUISP utilizes 
.ig >>
<a href="http://www.boutell.com/cgic">
.>>
\0CGIC 1.07
.ig >>
</a>
.>>
to fetch all CGI user variables.

.ig >>
<br><br><br>
.>>
.SH Masking the debug switch
.LP
The \fC_DEBUG\fR 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 
.ig >>
<a href="config.html#debugtag">
.>>
\0config debugtag setting.
.ig >>
</a>
.>>

.ig >>
<br><br><br>
.>>
.SH Other?
There may be other security issues that I am unaware of at the time of this writing.

.ig >>
<br>
<br>
</td></tr>
<td align=right>
<a href="quisp_home.html">
<img src="img/quisp2.gif" border=0></a><br>
<small>quick server pages &nbsp; &nbsp;<br>
<a href="Copyright.html">Copyright Steve Grubb</a> &nbsp; &nbsp;
</td></tr>
</table>
.>>
