Return-Path: 
 <apache-docs-return-2106-apmail-apache-docs-archive=apache.org@apache.org>
Delivered-To: apmail-apache-docs-archive@apache.org
Received: (qmail 87730 invoked by uid 500); 2 Oct 2001 15:37:08 -0000
Mailing-List: contact apache-docs-help@apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:apache-docs-help@apache.org>
list-unsubscribe: <mailto:apache-docs-unsubscribe@apache.org>
list-post: <mailto:apache-docs@apache.org>
Reply-To: apache-docs@apache.org
Delivered-To: mailing list apache-docs@apache.org
Received: (qmail 87695 invoked from network); 2 Oct 2001 15:37:07 -0000
From: "Joshua Slive" <joshua@slive.ca>
To: <apache-docs@apache.org>
Subject: RE: [PATCH] security_tips.html
Date: Tue, 2 Oct 2001 11:37:43 -0400
Message-ID: <ELEDJONBOPPAEGANDEEIEECICAAA.joshua@slive.ca>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Pine.LNX.4.33.0110011900500.4968-100000@ns1.vbind.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N



> -----Original Message-----
> From: Allan Liska [mailto:allan@allan.org]

> As Joshua suggested, I have separated the content changes from the
> formatting changes.  Listed below are the proposed content changes for the
> Server Side Includes section.  If they are acceptable, I will continue
> working the rest of the security tips documentation, according to the
> proposal outlined earlier.

Thanks!

> Any feedback is greatly appreciated.
>

See below.

> +<p>Server Side Includes (SSI), present a server administrator with
> +several potential security risks.</p>
> +
> +<p>
> +The first risk is the increased load on the server.  All SSI-enabled
> +files have to be parsed by Apache, whether or not there are any SSI
> +directives included within the file.  While this load increase is
> +minor, in a shared server environment it can become significant.</p>
> +
> +<p>
> +SSI files also pose the same risks that are associated with CGI scripts
> +in general.  A user can execute any CGI script through an SSI-enabled
> +file.  That should definitely give server administrators pause.</p>

I would say "A user can execute any CGI script or program" (see exec cmd).
You might also want to say "under the userid of the User and Group
configured in httpd.conf" and then mention how suexec mitigates this
problem.

> +
> +<p>
> +There are ways to enhance the security of SSI files, while still taking
> +advantage of the benefits they provide.</p>
> +
> +<p>
> +To start, never enable SSI for files with .html or .htm extension.
> +This is especially true in a shared, or heavily trafficked, server
> +environment.  SSI-enabled files should have a separate extension,
> +such as the conventional .shtml.  This helps keep server load at
> a minimum.
> +</p>

That is too strongly worded.  Using a different extension is a good idea for
security and management reasons, but you should remove "never".  If the
server is managed carefully, you can parse .html files without risk.  (You
have to realize that some people take what is written in the docs VERY
literally.  If you say "never" they assume the world will fall in if you try
it.  Of course, other people assume "never" means "go for it" ;-)

> +
> +<p>Another solution is to disable the #exec command withing  SSI. To do
> +that you use the IncludesNOEXEC option to the
> +<a href="../mod/core.html#options">Options</a> directive.</p>

I don't think the example directory block is necessary, but I would
explicitly state that you should use IncludesNoExec IN PLACE OF Includes.

Thanks again for being presistent about this!

Joshua.


---------------------------------------------------------------------
To unsubscribe, e-mail: apache-docs-unsubscribe@apache.org
For additional commands, e-mail: apache-docs-help@apache.org