On the PHPClasses.org blog there's a new post detailing an issue that came up in the PHP 5.3.9 release that caused a large security issue (PHP 5.3.10 has, however, already been released to correct the issue).

PHP 5.3.9 release was mostly meant to fix a security bug, but it introduced a new more serious bug. PHP 5.3.10 was just released to fix this issue. [...] This time it is a bug that allows arbitrary remote code execution. This means that it allows to run arbitrary code on the server, injected by an eventual attacker, so it can be used to cause many types of damage inside a server.

The upgrade to PHP 5.3.10 is highly recommended to prevent this issue from effecting your applications. The post also mentions the dropping of Suhosin support (a security plugin for PHP) on the Debian linux distribution's default installation and how the PHP community has reacted to the decision.

The PHP development team has officially announced the release of the latest version of PHP in the 5.3.x series - PHP 5.3.10:

The PHP development team would like to announce the immediate availability of PHP 5.3.10. This release delivers a critical security fix. [...] Fixed arbitrary remote code execution vulnerability reported by Stefan Esser, CVE-2012-0830.

It is highly recommended that users upgrade to this latest version to avoid falling victim to this recently introduced bug relating to the new "max_input_vars" setting added to protect from the overflow issue recently brought up in the PHP community.

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 a new post to his blog Paul Reinheimer talks about replacing sessions with cookies and some of the (security) pitfalls that can come with it.

I've seen several instances where people have demonstrated the ease with which encrypted cookies can replace sessions within PHP. Michael Nitschinger wrote a piece recently demonstrating the switch with Lithium, while CodeIgniter does this by default (optionally encrypting). The problem is that while replacing sessions with cookies works, it introduces a few risks not present with native session support, and these risks tend to be under documented.

He gives an illustration of an attacker who sits between Amazon and one of their warehouses. Despite encrypting their order details, all it would take is the attacker to grab an order and copy it and resend (a "replay attack"). He's created an example application to illustrate the point (source on github). The attacker doesn't even have to know what the encrypted information contains - they only have to replicate it.

In a new post to his blog Henrik Bjørnskov has a tip on preventing cross-site request forgeries in your Symfony2 forms with the help of a simple Symfony2 configuration setting.

When talking with @jmikola on #Symfony-dev this afternoon we got into the subject of cross site request forgery and symfony2 login forms. And it seems that form-login already supports this but neither of us knew how it worked. So here is another quick tip. This time about securing you login form from cross site attacks.

The key is to define a "csrf_provider" in your security.yml config file and point it to the "form.csrf_provider" provider. He also includes the controller and view code/templating you'll need to get the token included in the form (and validated).

Henrik Bjørnskov has a quick new post with a security tip for those using the Symfony2 framework in its configuration.

Earlier when playing around with the Security component and SecurityBundle i found that for all paths you can specify a route name and the component will match it when check for the request paths.

Setting this up in your configuration gives you more control over the paths that are matched as well as more flexibility in defining them. He includes a note about a change you might have to make to the SecurityBundle's code to get the "check_path" part working correctly. You can find out more about the SecurityBundle's integration in this blog post from Pablo Bandin.

In this new post to Reddit, the author shares a bit of their knowledge on what they think everyone should know about strip_tags and some of the issues that can come with it (including security problems).

strip_tags is one of the common go-to functions used for making user input on web pages safe for display. But contrary to what it sounds like it's for, strip_tags is never, ever, ever the right function to use for this and it has a lot of problems.

Specific problems mentioned include "eating" of valid text, not preventing typed HTML entities, the whitelist of tags opening holes and character set issues that could have security implications. Other tools are recommended in both the article and the comments like HTML Purifier, the option of BBCode and Markdown.

In the fourth part of their series looking at working with the filesystem in PHP, DevShed has posted a new tutorial focusing on security and permission handling for files/resources.

These days, security is paramount to any server installation, large or small. Most modern operating systems have embraced the concept of the separation of file rights via a user/group ownership paradigm, which, when properly configured, offers a wonderfully convenient and powerful means for securing data. In this section, you'll learn how to use PHP's built-in functionality to review and manage these permissions.

They introduce functions like:

• chown
• chgrp
• fileperms
• isexecutable
• umask

Sample code is also included to show how to open and close a file.

On PHPMaster.com today there's a new introductory tutorial for those trying to figure out sessions in PHP. Sessions can be one of the most powerful tools at your disposal and handling them correctly can sometimes be a little tricky.

$_SESSION is a special array used to store information across the page requests a user makes during his visit to your website or web application. The most fundamental way to explain what a sessions is like is to imagine the following scenario: You are working with an application. You open it, make some changes, and then you close it. That is a session in it's simplest form.

They start with a basic "how to use them" example of setting a username value to the current session and pulling the value back out. They also show the use of the session_unset and session_destroy methods for ending the session. Some security tips are mentioned too - timeouts, regenerating the session ID, destroying them correctly and using a more permanent storage option (by default, they store on the local disk).

Johannes Schmitt has a new post about his "killer feature" he's added to the security for Symfony2 framework (as a bundle) - a new customized expression-based query language that's compiled down to native PHP to make permissions checking simpler and faster.

If you have used the Symfony2 Security Component to any modest degree, you will know that we have a quite heavy voting system which uses attributes like "IS_AUTHENTICATED_FULLY" to make authorization decisions. [...] If you are concerned about performance, then you should not be all too generous with the isGranted() calls. The second option would work as well, but writing a new voter each time you need to make a new check does not really seem ideal either. Fortunately, we can do better.

He includes an example of this expression language in a direct isGranted() call, a string that checks to see if a user has three different roles, and a snippet showing the same thing in the docblock comment of a controller method. The second is a bit more complex, checking for an admin role or if the user is the one that should be deleted. You can find more doucmentation here.