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-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
