On his Medium.com site Nicolas Grekas talks about a new RFC that's been proposed to provide a safer method for serializing and unserializing values in native PHP functionality.

PHP serialization/unserialization has several drawbacks. [...] To mitigate these security issues, the unserialize() function handles an allowed_classes option since PHP 7.0. Implementing Serializable has this security-mitigation advantage of allowing authors to filter the allowed classes in the subgraph managed by their objects. This feature is only a mitigation because not all use cases know all the possible classes beforehand.

He starts by listing out some of the issues with both the current implementations of serialization and unserialization in PHP. From there he makes a proposal for some new functionality to help make things a bit more sane:

• a __serialize magic method
• a new S type representing serialized data
• a new __unserialize magic method
• automatic protection around destructors during the unserialization process

He finishes up the post talking about some of the expected benefits of this kind of functionality and a few of the extra considerations that would need to be thought through as a part of the implementation.

The Paragon Initiative site has a new tutorial posted aiming to help you more securely use the serialize and unserialize handling in PHP to prevent security issues. In this tutorial they offer some advice - mainly don't unserialize unless you're on PHP7 - and some other solutions you could use.

A frequent problem that developers encounter when building web applications in PHP is, "How should I represent this data structure as a string?" Two common examples include:

• Caching a complex data structure (to reduce database load)
• Communicating API requests and responses between HTTP-aware applications

This seems like the sort of problem that you could expect would have pre-existing, straightforward solutions built into every major programming language that aren't accompanied by significant security risk. Sadly, this isn't the case.

He starts with a look at the serialization handling and how it could allow remote code execution if an attacker were to modify the serialized data. He includes an example of using the new "allowed classes" parameter in PHP 7 too, though, preventing the issue. He also walks through two other ways you could replace serialized data: JSON structure and XML handling. Each of these have their own issues too but they're very different than the code execution with serialization.

Stanislav Malyshev has a new post to his site talking about his proposal for a filtered unserialize change and why he sees it as a practical next step.

I have recently revived my “filtered unserialize()” RFC and I plan to put it to vote today. Before I do that, I’d like to outline the arguments on why I think it is a good thing and put it in a somewhat larger context. It is known that using unserialize() on outside data can lead to trouble unless you are very careful. Which in projects large enough usually means “always”, since practically you rarely can predict all interactions amongst a million lines of code. So, what can we do?

He touches on three points that would make it difficult to just not use it this way (on external data) including the fact that there's not really any other way to work with serialized data in PHP. He suggests that by adding filtering to the unserialize handling of the language it can protect from issues around working with serialized external data.

Is this a security measure? [...] Yes, it does not provide perfect security, and yes, you should not rely only on that for security. Security, much like ogres and onions, has layers. So this is trying to provide one more layer – in case that is what you need.

In this new post Josh Adell looks at working with PHP sessions and how you can manually encode data to look as if it came from the normal session handling.

If you have ever popped open a PHP session file, or stored session data in a database, you may have noticed that this serialization looks very similar to the serialize function's output, but it is not the same. Recently, I needed to serialize data so that it looked like PHP session data (don't ask why; I highly suggest not doing this if it can be avoided.) It turns out, PHP has a function that encodes data in this format: session_encode.

Unfortunately, this method doesn't take arguments - it just outputs the encoded version of the current session data. So, he came up with his own encode/decode methods that use the PHP session, extract the serialized string and return it.

Pavel Shevaev has posted his method (a reliable way) for serializing and unserializing objects in your applications:

An experienced PHP developer might be wondering why posting this topic in a blog if PHP already has universal and almost transparent tools for this job [...] The key statement here is "almost transparent" which means you have to include all class definitions before invoking unserialize or use some __autoload schema.

The whole problem is due to the fact a serialized object has no idea about its class definition except the class name(the reason behind that is absolutely valid). [...] That's why I decided to hack up, hopefully, a more universal solution to this problem

His method contains things inside of a "serialization container" that automagically includes everything needed before it gets serialized. His code for the method is included as well as some examples of its use.

Pavel Shevaev has posted his method (a reliable way) for serializing and unserializing objects in your applications:

An experienced PHP developer might be wondering why posting this topic in a blog if PHP already has universal and almost transparent tools for this job [...] The key statement here is "almost transparent" which means you have to include all class definitions before invoking unserialize or use some __autoload schema.

The whole problem is due to the fact a serialized object has no idea about its class definition except the class name(the reason behind that is absolutely valid). [...] That's why I decided to hack up, hopefully, a more universal solution to this problem

His method contains things inside of a "serialization container" that automagically includes everything needed before it gets serialized. His code for the method is included as well as some examples of its use.

From the "Make Me Pulse" blog (of Nicolas Rajabaly & Antoine Ughetto) there's a quick example of how to use serialized values with SimpleXML:

Serialize is useful for storing or passing PHP values around without losing type and structure. But if you want to serialize a SimpleXml object, you will have some problem on unserialize with the error. [...] Replacing SimpleXMLObject with stdClass is a good idea but in this solution we loose all of attributes, and how can we make simplexml->xpath after?

The solution? Serializing the XML content and then outputting it from the SimpleXML object as an XML string (to be stored). This process is reversed when the data is needed back out.

From the "Make Me Pulse" blog (of Nicolas Rajabaly & Antoine Ughetto) there's a quick example of how to use serialized values with SimpleXML:

Serialize is useful for storing or passing PHP values around without losing type and structure. But if you want to serialize a SimpleXml object, you will have some problem on unserialize with the error. [...] Replacing SimpleXMLObject with stdClass is a good idea but in this solution we loose all of attributes, and how can we make simplexml->xpath after?

The solution? Serializing the XML content and then outputting it from the SimpleXML object as an XML string (to be stored). This process is reversed when the data is needed back out.

The Hardened-PHP project has just released another advisory about core PHP functionality, specifically in the unserialize function when dealing with arrays.

The PHP 5 branch of the PHP source code lacks the protection against possible integer overflows inside ecalloc() that is present in the PHP 4 branch and also for several years part of our Hardening-Patch and our new Suhosin-Patch.

It was discovered that such an integer overflow can be triggered when user input is passed to the unserialize() function.

You can get the full details from this advisory release including a recommendation to patch the installation until it is corrected in the current distribution.

The Hardened-PHP project has just released another advisory about core PHP functionality, specifically in the unserialize function when dealing with arrays.

The PHP 5 branch of the PHP source code lacks the protection against possible integer overflows inside ecalloc() that is present in the PHP 4 branch and also for several years part of our Hardening-Patch and our new Suhosin-Patch.

It was discovered that such an integer overflow can be triggered when user input is passed to the unserialize() function.

You can get the full details from this advisory release including a recommendation to patch the installation until it is corrected in the current distribution.