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 PornHub.com site (definitely NSFW) is a high profile site that, as it turns out, uses PHP for a lot of its functionality. In this interesting article from the Evondie Security Research Group they show how they "broke PHP and hacked PornHub (and earned a $20k USD bug bounty in the process). Don't worry, the article itself is "safe for work" as it's only descriptions and code examples of how the hack was performed.

Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why we have taken the perspective of an advanced attacker with the full intent to get as deep as possible into the system, focusing on one main goal: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP.

The post then walks you, step-by-step, through the process they followed to discover the exploit. The main entry point was through PornHub's use of the unserialize function that included a flaw allowing for code execution when a specially crafted object was injected. With the help of this they were able to "leak" out of the PHP execution and inject custom C code to be executed in the local environment. This was, in turn, then used to execute a file_get_contents on the local /etc/password file and return its contents.

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.

Phil Sturgeon as a new post to his site today talking about the importance of serialized API output and why it's important to think about what to share and how they're shared.

One section that seems to get a lot of feedback and questions is when I talk about serialization, which I refer to as “adding a presentation layer to your data”. [...] To PHP developers, they often consider serialization to be using the serialize() function. Yes, this is one form of serialization, but it’s not the only one. Another common serialization approach is of course to use the json_encode() function. [...] Excuse the drastically simplified chunk of code here, but the point is we’re taking a model (probably using an ORM) and returning the result directly. This seems fairly innocent, but leads to a range of problems.

He suggests that, when thinking about the data coming out of your API, you have to assume that every possible value could be shared if models are output directly. He gives the example of user passwords which, obviously, don't need to be shared at all. He includes an example of formatting the output with the Fractal library and why using something like that is important. He covers some of the topics to think about including attribute data types, renaming fields to make them more clear, the ability to pull from multiple data stores and the ability to version serializers. He ends the post with links to a few different serialization formats and some solutions (not just PHP ones) that can be used for the sort of handling he recommends.

The Programming Are Hard site continues its look at structuring Symfony-based applications in part two (it's just two parts) building on the structure and foundation laid out in part one.

It really irks me when I see some design/architecture decisions other developers have made but there's no technical explanation. What packages did they use? What challenges did they face? What trade-offs were made? I'll go over some more specifics in this post.

He recaps some of the things covered in the previous post first, ensuring everyone is on the same page. He then gets into the concept of "bundles" and how they encapsulate functionality. From there he talks about commands, controllers, dependency injection and lots of other topics, each with their own summary and a bit of code where needed for clarification.

In this recent post to Reddit.com, they point out a recent change in the core of PHP that could cause problems with backward compatibility: a change in the serialization handling to check for implementation of the Serializable interface.

Strings requiring unserialization of objects are now explicitly checked whether the object they contain implements the Serializable interface. This solves the situation where manipulated strings could be passed for objects using Serializable to disallow serialization. An object implementing Serializable will always start with "C:" in the serialized string, all other objects are represented with starting "O:". Objects implementing Serializable to disable serialization using zend_class_unserialize_deny and zend_class_serialize_deny, when instantiated from the serializer with a manipulated "O:" string at the start, will most likely be defectively initialized. This is now fixed at the appropriate place by checking for the presence of the serialize callback in the class entry.

The change corrects a bug that has been used, in certain cases, as a work-around to create objects without calling the constructor. The correct fix for it, if you're using it in your own applications, is to call ReflectionObject::newInstanceWithoutConstructor.

In this recent post over on DZone.com Giorgio Sironi takes a look at the "clone" feature of PHP - what it is, how it can be used and things to watch out for in its use.

Cloning is an operation consisting in the duplication of a data structure, usually to avoid the aliasing problem of having different code modify the same instance in inconsistent ways. In PHP, cloning can be accomplished in multiple ways - and in some cases it can be avoided altogether.

He talks some about how objects are passed around internally during the PHP execution and how you can tell if a function works with data by reference (from the manual). He then looks at the "clone" keyword and what kinds of things are duplicated from an object when it is used. He briefly touches on the "__clone" magic method for solving the "shallow clone" problem and how, possibly, serializing the object might be a better alternative for reproducing the entire object.

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.

Michael Nitschinger has written up a new post comparing a few different methods for serializing or translating objects to store them in a cache. In it, he compares the PHP serializer, the igbinary extension and translation to JSON.

Storing PHP objects (or simpler data types like arrays) in caches always requires some kind of transformation. You need a way of encoding/decoding data so that it can be stored and loaded properly. In most languages, this process is known as object serialization. PHP provides a mechanism for this out of the box, but in this article we'll also look at igbinary as a drop-in replacement for the default serializer. We also compare the results to object transcoding based on JSON, which is not really an object serialization mechanism but commonly used as a data chache structure which has its own benefits and drawbacks.

He goes through each of the three technologies and includes a snippet of code showing how they'd work in object translation. He also talks about things like the size of the result and the performance of each when the results are looped over. Based on the results of some of his "microbenchmarking" of each of the methods, igbinary came out on top, even faster than PHP's own serialize/unserialize.

In this new post to DZone.com today Giorgio Sironi takes a look at the serializing functionality in PHP and how it works with both regular variables and objects.

PHP is able to automatically serialize most of its variables to strings - letting you save them into storage like $_SESSION. However, there are some tweaks you have to know to avoid exploding .php scripts and performance problems.

He gives some code snippets showing the serialization of variables and objects and points out a few things that can't be effectively serialized (like resources and closures). The mentions the "__sleep" and "__wakeup" magic methods for automatic class serialization and mentions the Serializable interface that comes built in to PHP.