Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of kbenson@corp.sonic.net
 designates 64.142.16.245 as permitted sender)
Message-ID: <4F96E9A9.409@corp.sonic.net>
Date: Tue, 24 Apr 2012 10:58:01 -0700
From: Kevan Benson <kbenson@corp.sonic.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:11.0) Gecko/20120312 Thunderbird/11.0
MIME-Version: 1.0
To: users@httpd.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [users@httpd] Community best practices WRT PHP processing


I'm looking for some input on what the community best practices are with
regard to specifying which files to apply PHP processing to.

Historically, many distributions have used AddHandler to accomplish
this, but depending on the environment where PHP is being used, this can
lead to other unintended consequences, such as processing files as PHP
source when they should not be (due to Apache's multiple file extension
handling)[1].

PHP's solution to this seems to be to use a FilesMatch directive with
SetHandler to ensure only files ending in ".php" are processed, and
processed only as PHP files.

Should this be considered the correct way to define files to process as
PHP to work around this problem[2]?  What are the performance
implications of doing a FilesMatch for every request?  Are there any
other consequences of adopting this[3]?


[1] A simple illustration of this is that file.php.txt or file.php.1
will be processed as PHP, not shown or offered for download.  When
combined with any sort of software that allows uploading to a web
location (which may blacklist based on extension), if file.php.txt or
file.php.pdf is uploaded, we may have an exploitable situation where
arbitrary code can be executed on the server.

[2] While the best solutionis probably a white list (at the server
configuration level and/or at the web application level for uploads),
the truth is that relying on others to do the right thing for your
security is a failed model from the beginning.  Additionally, this issue
is clouded by the fact there may be two sets of best practices; what to
do if you have full control over the web server configuration for your
small set of applications it services, and what to do when running a
hosting platform where what is served by Apache is constantly changing
and can't be reasonably vetted by security conscious personnel.

[3] One that comes to mind is how to handle the numerous locations where
people have made naive backups of PHP files by adding extensions such
.bak, .save, .old, etc to existing PHP files.  Often these are
configuration files, and exposing them to the public may constitute its
own security implications.  A second FilesMatch for \.php\. could be
used to prevent these from display at all, possibly with a custom error
message.

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