Quoting Dr. Larry Ozeran (loze...@clinicalinformatics.com): > Thanks Rick. > > This is why I have such great respect for the members of this list. > You have such valuable experiences that you are willing to share. I > regret that I have had the experience of server issues occurring at > bad times (right after talking about our product at a trade event), > but thus far none have been PHP or MySQL related, so I very much > appreciate the insights of others.
Looking over my notes about tightening PHP security (direct link http://linuxmafia.com/faq/Security/php.html), I see something I might consider writing more about (in that piece): I talk about several prototype files Debian provided for /etc/php5/apache2/php.ini , specifically: /usr/share/doc/php5-common/examples/php.ini-paranoid /usr/share/doc/php5-common/examples/php.ini-recommended The thing is, the distribution-provided /etc/php5/apache2/php.ini file stated in header comment lines... well, let me just quote it: ;;;;;;;;;;;;;;;;;;; ; About this file ; ;;;;;;;;;;;;;;;;;;; ; PHP comes packaged with two INI files. One that is recommended to be used ; in production environments and one that is recommended to be used in ; development environments. ; php.ini-production contains settings which hold security, performance and ; best practices at its core. But please be aware, these settings may break ; compatibility with older or less security conscience applications. We ; recommending using the production ini in production and testing environments. ; php.ini-development is very similar to its production variant, except it's ; much more verbose when it comes to errors. We recommending using the ; development version only in development environments as errors shown to ; application users can inadvertently leak otherwise secure information. So, thing is, I could swear that the _default_ php.ini Debian installed to /etc/php5/apache2/php.ini was the _development_ variant -- because when I got around to looking through it and locking it down, I was a bit shocked at the high default security exposure. It was exactly as I was working through that file, commenting out dangerous and unneeded optional interpreter features, that I wrote my modest hardening guide (more as notes for my own benefit than with any intent to publish). That experience was one of my first signs that something was not right with PHP and its security posture. It might be my imagination, but I think part of what's happening is that only lip service is normally given to enabling only the language functionality actually necessary; that many developers of PHP developed applications blithely expect deploying sites to have the kitchen-sink set of language functions available and their code mysteriously fails if you don't. So, deploying sites are passively led into bad habits and bad defaults. And, for example, picture a world where the developers gravitate towards php.ini-development and sysadmins towards php.ini-production. What's going to happen as a natural tendency? You know developers; they'll happily use the features in front of them, which then will ratchet up the need for those in deployment. Not good. It's a bad sign when the development default environment includes bad security and the attitude is 'be unsafe only while developing code and we'll fix it all up later'. A brief clarification: The incursion that happened just as I got on an ocean cruise this past February happened _despite_ all the security tightening, on account of yet another grave flaw in the core mod_php code. (I cannot tell you which flaw because I elected to just disable the thing rather than work further on it.) _______________________________________________ vox-tech mailing list vox-tech@lists.lugod.org http://lists.lugod.org/mailman/listinfo/vox-tech