In this recent post to his blog Anson Cheung provides a set of helpful hints for sysadmins to follow when installing (or just securing) the PHP installations on their systems.

PHP is widely used for various of web development. However, misconfigured server-side scripting would create all sorts of problem. And here are php security best practices that you should aware when configuring PHP securely. Nowadays most of the web servers are operated under Linux environment (like: Ubuntu, Debian...etc). Hence, in the following article, I am going to use list top 10 ways to enhance PHP Security Best Practices under Linux environment.

His tips include:

• Reducing the built-in PHP modules
• Logging all PHP errors
• Disabling remote code execution
• Disabling dangerous PHP functions
• Write protection on Apache, PHP & MySQL configuration files

In an interesting post to his blog Kyle Brandt asks a question universally debated by system administrators everywhere - should developers have access to production?

A question that comes up again and again in web development companies is: 'Should the developers have access to the production environment, and if they do, to what extent?' My view on this is that as a whole they should have limited access to production. A little disclaimer before I attempt to justify this view is that this standpoint is in no way based on the perceived quality or attitude of the developers '" so please don't take it this way.

He talks about common excuses from developers like "we've had access before" and "we need access to troubleshoot" as well as some of the process restricting the access could create. He touches on a few other issues including developer concerns vs those of the sysadmin, change control issues and the responsibilities of the sysadmin administrators if they want to allow the developers to poke around their servers.

Be sure to check out some of the other great suggestions in the comments too!

As mentioned by the php|architect website, the results are in for the Community Awards competition SourceForge was hosting for the year and two PHP-based projects made the list - phpBB and phpMyAdmin.

The Community Choice Awards are over! The SourceForge.net 2007 Community Choice Awards provided you an opportunity to recognize projects that stand taller than the rest. Everybody got to vote, and everybody’s vote counted equally. The winning projects, each with superlative quality, productivity, and ingenuity, represent the cream of the crop on SourceForge.net.

phpBB made the cut in the "Best Project for Communications" category and phpMyAdmin won in the "Best Tool or Utility for SysAdmins". Congratulations to both projects on your achievement!

As mentioned by the php|architect website, the results are in for the Community Awards competition SourceForge was hosting for the year and two PHP-based projects made the list - phpBB and phpMyAdmin.

The Community Choice Awards are over! The SourceForge.net 2007 Community Choice Awards provided you an opportunity to recognize projects that stand taller than the rest. Everybody got to vote, and everybody’s vote counted equally. The winning projects, each with superlative quality, productivity, and ingenuity, represent the cream of the crop on SourceForge.net.

phpBB made the cut in the "Best Project for Communications" category and phpMyAdmin won in the "Best Tool or Utility for SysAdmins". Congratulations to both projects on your achievement!

In a new post on his blog, Christian Wenz mentions the latest results of the SANS Institute's Top 20 Internet Security Attack Targets list which both includes a new entry ("Users") and several mentions of PHP and PHP-related applications.

Of course you can debate how such a Top list came together and what the real value behind that is, but there are two specific points in this year's list that I found quite interesting.

There's two targets for the PHP community to worry about - sysadmin/hosting and things developers need to keep in mind. Items on these lists include:

• Always test and deploy patches and new versions of PHP as they are released
• Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks
• If you use PHP, migrate your application to PHP 5.2 as a matter of urgency.
• Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks

In a new post on his blog, Christian Wenz mentions the latest results of the SANS Institute's Top 20 Internet Security Attack Targets list which both includes a new entry ("Users") and several mentions of PHP and PHP-related applications.

Of course you can debate how such a Top list came together and what the real value behind that is, but there are two specific points in this year's list that I found quite interesting.

There's two targets for the PHP community to worry about - sysadmin/hosting and things developers need to keep in mind. Items on these lists include:

• Always test and deploy patches and new versions of PHP as they are released
• Use Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. Consider using Apache's mod_security to block known PHP attacks
• If you use PHP, migrate your application to PHP 5.2 as a matter of urgency.
• Encode all output using htmlentities() or a similar mechanism to avoid XSS attacks

On the SitePoint PHP Blog today, Harry Fuecks takes a look at why PHP from a sysadmin's perspective.

A funny from the Python crowd: phpfilter—PHP "support" under CherryPy. There is a serious side to that though—it's spitting out something that looks like a PHP parse error—i.e. this is a developer problem (e.g. someone ftp’d a PHP straight onto their live web server for “testing”), not a runtime error.

More to the point, when was the last time you saw a PHP runtime error take down an entire application or web server? And no - "MySQL Connection Failed: Can't connect to local MySQL server" doesn’t count—PHP and the web server are still running—the MySQL server (or otherwise) is to blame.

He also looks at a slightly different method for serving up web applications - with FastCGI. He talks about the basic features of a server (forking, threading, asynchronous I/O) and how that explains how we've ended up with PHP being the "lesser of the evils"...

On the SitePoint PHP Blog today, Harry Fuecks takes a look at why PHP from a sysadmin's perspective.

A funny from the Python crowd: phpfilter—PHP "support" under CherryPy. There is a serious side to that though—it's spitting out something that looks like a PHP parse error—i.e. this is a developer problem (e.g. someone ftp’d a PHP straight onto their live web server for “testing”), not a runtime error.

More to the point, when was the last time you saw a PHP runtime error take down an entire application or web server? And no - "MySQL Connection Failed: Can't connect to local MySQL server" doesn’t count—PHP and the web server are still running—the MySQL server (or otherwise) is to blame.

He also looks at a slightly different method for serving up web applications - with FastCGI. He talks about the basic features of a server (forking, threading, asynchronous I/O) and how that explains how we've ended up with PHP being the "lesser of the evils"...