PHP security issues are similar to the normal cgi security issues, stemming from the fact that all virtual sites on a single server will have the same read/write permissions for all areas. PHP adds to this in that it is a shared module within apache, so there are also enviornment based issues.
The main difference between php sites and regular/cgi sites is that most php sites are using php for some sort of database access. The database authentication information therefore needs to be saved somewhere that PHP can read it, and because of this, any other virtual site can use a php or cgi script to read that information as well.
This can be mitigated somewhat if the site doing php doesn't allow cgi scripts by limiting the ability to display php files without them being interpreted, but if cgi scripts are available there is almost certainly a way to avoid this restriction.
The biggest threat therefore is from other users of the same server, so in that regard the Lab Computing Policy protects people from other users poking around their files. While hackers may be able to break in and find information about other sites, external attacks are much more likely to result in defacement and unwanted file uploading.
Many sites use PHP with session support. This requires that all requests from a client go to the same webserver. Fortunately the Alteon switch can handle this based on either looking for a specific Cookie or a URL pattern. The cookie based approach would probably be slightly more secure. Due to current Lab policy concerning cookies, we will need to make sure the cookies are only saved for the current browser session.
PHP Access should be limited to the sites/directories that need it.
PHP can be turned on in both <VirtualHost> and <Directory>
blocks.
There are several global options that affect PHP behavior. One of
the most common to come up is the "register_globals" option which
automatically converts cookies, form fields, and certain enviornment
variables to global variables. This can cause security problems. Most
reasonable php applications these days are written to not require this,
so it should be turned off.
There is a safe-mode in php, but it is probably too restrictive to
use system-wide, as many popular pre-built php applications will not
work with it.
There are options to limit access to specific directories, including
".", which limits scripts to their own directory and below. Other
useful security related PHP global options can be found at this link.
Each author is fully responsible for the security of their site. It is up to them to make sure any pre-build php applications get any needed security updates. It is up to users using pre-built php applications like PHP-Nuke, etc. to make sure they keep up with the latest security updates and patches for their application. This is the single most popular source of web site security breaches these days. The web site where the code was obtained should have a mailing list or other information on how to keep informed on updates. It is very important that this be monitored regularly, and if resposibility for the maintainance of the site changes hands, that the new maintainers are aware of where to get this information.
Directories that need to be written to by PHP scripts will explicitly need their permissions set to allow the webserver ip write access to that directory. It is strongly recommended that such directories be limited to just saved data and not other php scripts, as they could potentially be overwritten with malicious code.
It is importnat that people not be able to post messages, files, or other content anonymously. Any web app, either written by the user or prepackaged like PHP-Nuke,etc. Must be configured so that either users must log in with a username and password, or anything they would post anonymously will be reviewed by authorized persons before being published on the web.
All input needs to be parsed carefully. All input that will be displayed on the web or saved in a database or elsewhere should be carefully parsed for hidden html, javascript, PHP, and SQL code. This includes scanning all fields for unwanted meta characters.
It is recommended that everyone take a look at the security chapter in the PHP manual.
Users must make sure all their php scripts are named with a *.php extension, including files that are only included by other php scripts. This will allow admins to be able to identify any files that require php if a need arises.
Users are responsible for making sure their scripts will function correctly when php versions are upgraded on the central servers. The administators will try to provide as much notice as possible before any upgrades.
Users should familiarize themselves with the "cgi security" section of the Fermilab Webmasters document. Many of the same issues and concerns apply to php scripts. The page is located at http://www.fnal.gov/cd/webgroup/idocs/webmaster_info.html.