In a new post to his site Aaron Saray has shared two tips that can help you protect the information in your PHP sessions - two configuration options to enable that can enforce stricter standards and options enhancing their overall security.

Let’s talk a little bit about session fixation in PHP. Such a fun topic, right? Tons to get into here. But, let’s just touch the surface on two VERY SIMPLE things you can be doing now to make sure that your website is safe.

The two configuration options he mentions are ones that:

• force the session identifier to use cookies (versus also allowing it from the URL)
• enforce "strict mode" on the sessions

Each comes with a bit of description as to what the setting does and the recommended setting is to provide the most protection. One note, though: strict mode is only included in PHP 5.5.2 or greater.

The Dzone.com site has a recently posted tutorial helping you understand the php.ini, the main configuration file PHP uses to set up its own internal features and settings.

our php.ini file provides a considerable amount of power over the behavior of your PHP application ecosystem. Let’s jump into some of the most common declaratives and discuss how they impact your application performance and behavior. I won’t go into an explanation of each setting that is available, but I’ll cover the fundamental options that you should be aware of. Please keep in mind that changing any of the settings on in your php.ini can and may very well change the behavior of your application, whether positive or unfavorable. Please use caution when adjusting your settings, consult with your team, do your research, understand the implications, and, of course, test, test, and test again before deploying anything into production!

He starts with a brief introduction to what the php.ini file is and how you can use the phpinfo function to find the current settings in HTML form (on the command line it's "php -i"). He then goes through and covers some of the basics from the standpoint of security, memory handling and some general settings.

Simon Holywell has a new post talking about cookie security in PHP, focusing on some of the PHP configuration settings that can help.

The security of session handling in PHP can easily be enhanced through the use of a few configuration settings and the addition of an SSL certificate. Whilst this topic has been covered numerous times before it still bears mentioning with a large number of PHP sites and servers having not implemented these features.

He talks about the httponly flag when setting the cookie/in the configuration, the "use only cookies" for sessions and forcing them to be "secure only".

Chris Jones has a new post to his Oracle blog today talking about the new "opcode" opcode caching that's going to be built into future PHP versions This is the implementation of the Zend Optimizer+ opcode caching in a native language interface. The latest PHP 5.5 snapshots have it included.

The new "opcache" can be seen as substitute for the venerable APC cache, the maintenance of which had become an issue. Note: although opcache is now readily available, there is currently nothing preventing you from using any available (working!) opcode cache in PHP 5.5.

He gives you a quick guide to getting this new opcode caching enabled and compiled into a shiny new download of the PHP 5.5.x branch. You'll need a special command line flag on the compile and to update your php.ini to load the needed shares module. You can also use it if you're on PHP 5.2 or higher either by compiling this source or using this PECL extension.

On PHPMaster.com there's a continuance of a previous article about security in PHP applications talking about a few more considerations when trying to make things secure.

In a previous article, I talked about some common security vulnerabilities that can affect your PHP web application. But there are other things besides those ten (okay, seven) attacks to think about when you’re developing. And so, this article offers a compendium of miscellaneous things that are security related; things you should do, things you shouldn’t do, things that other people might try to do, whatever it takes to make an article long enough for my editor to be satisfied with it.

He talks some about the settings that you might need to tweak in your "php.ini" server-side configuration file, some hints on filtering data (like using filter_input) and what to watch out for with error reporting. He also mentions session fixation and the protection of user data and passwords to keep them out of the hands of would-be attackers.

On PHPMaster.com today Callum Hopkins has written up an introduction to the php.ini, the heart and soul of any PHP installation. With configuration options for just about everything, it can be confusing. This tutorial hits some of the highs and most commonly updated settings.

Anyone who has a server using PHP has undoubtedly heard of php.ini - it's the configuration file used to control and customize PHP's run-time behavior. It provides a simple way to configure settings. [...] In this article I’ll give an overview of some important settings I believe you should be concerned with when tweaking your own php.ini file.

The tutorial's broken up into a few different topics:

• the PHP engine
• Short tags
• Output buffering
• Automatic headers and footers
• Handling errors
• Time zones

If you're relatively new to the PHP world, you may be wondering why there has been so much emphasis put on "magic quotes" in the language's past. If you're not entirely sure what they are (and why to avoid them) take a look at this quick overview from XpertDeveloper.com.

First of let me say that Magic Quotes is deprected from the PHP 5.3 and will be removed completely from the PHP 6. But as a developer you might face a situation when you have to work on application which runs on older version of PHP with some older functionality like rely on Magic Quotes.

They introduce the simple concept behind the magic quotes idea and, thankfully, the settings and code you can use to turn it off. It's been deprecated in PHP 5.3 but some older versions came with it enabled. If you're currently running with it on, it's highly recommended to turn it off and refactor your code accordingly.

Jason Gilmore gets "back to basics" in a new tutorial with a look at managing configuration in your ini file to tune it to just what you need.

While PHP's configuration capabilities are indeed powerful, the sheer breadth and different ways in which these configuration directives can be set are often confusing and downright intimidating to newcomers. So in this article it worth meandering from the typically intermediate-level discussion and instead offer some insight into PHP's configuration-specific infrastructure.

He starts by mentioning the phpinfo function that generates the complete list of current settings for your installation. With that in hand and an idea of what settings are out there, he starts going through some of the basics of working with ini settings - updating the php.ini, setting values via a .htaccess file and chancing them directly in the executing script.

Brian Swan has a new post today looking at how you can update some PHP settings in your Windows Azure instance - an alternative to redeploying your every time your php.ini file might need an update.

I came across this question on Twitter last week: "How can I turn display_errors on for an application that is running in Windows Azure?" I have to admit that I was stumped. The only thing I could think of was to re-deploy the application with an updated php.ini file. But, I happened to mention this question to Ben Lobaugh who suggested a very simple idea: Store your PHP settings in some durable store external to your application as key-value pairs, then loop through the settings and update them with the ini_set function when a page loads.

He puts a big disclaimer on his suggestion, noting that it's "a hack and only a hack" and can be useful for someone still learning how to work with Azure and deployment. He shows how to use a Table storage to save the values and make them easier for the application to grab at runtime. Using the tools from their SDK, fetching and setting those values is a simple process. An idea like this, while convenient, could potentially cause performance issues down the line, do be careful with this recommendation (and be sure to load test).

Giorgio Sironi has a new post to the DZone.com Web Builder Zone today giving a high-level guide to some of the PHP errors you could encounter in your development time.

While pure object-oriented languages produces mainly exceptions to signal an error, PHP started out as procedural and so it has a wide range of errors that can be raised along with exceptions.

He talks about a few of the most common error related issues:

• Exceptions
• Errors
• Error Types (E_NOTICE, E_PARSE, etc.)
• php.ini directives
• PHP functions for setting error handlers