Predicting the Future of PHP Security – Part 3

By | | 8 min read

In some ways security is an infinite game of chess on a board the size of the world. For every move you make, the hackers have a countermove ready. They are highly motivated to take what you have, so the game never ends; it just switches players once in awhile.

In some ways security is an infinite game of chess on a board the size of the world. For every move you make, the hackers have a countermove ready. They are highly motivated to take what you have, so the game never ends; it just switches players once in awhile. In this final blog in the series, we are going to review the game board, with a look at the most recent changes to security in PHP 7 and earlier supported versions. Then, we’ll try to look a few moves ahead with predictions for the future of PHP security.

The Problem with Popularity

It is understandable that PHP has attracted a considerable amount of attention from hackers because it is one of the most popular programming languages on Earth, according to the TIOBE index.

In various versions, PHP is currently running underneath the vast majority of sites on the web. Web Technology Surveys reported that PHP is used by about 82 percent of all websites where it is possible to know the server-side language.

PHP 7 Released

The biggest change in the landscape since we left off in Part 2, is that PHP has gone in for a complete makeover. PHP 7 was released in December, the first major update in more than a decade and coming in with an emphasis on faster loads and new functionalities. In case you were wondering what ever happened to PHP 6, it did not happen at all. Unicode failures were too severe, and it had to be scrapped.

This year, some security updates have already been issued, so check on the site to make sure you have the latest update. They are also still supporting the 5.5 and 5.6 release with a number of security patches.

The new release is confirmed to be faster and more stable by plenty of benchmarks and testing sites. The official benchmarks validate PHP 7 running twice the speed of PHP 5.6 in common deployments. The update handles double the number of requests per second, so most users with typical applications like WordPress sites will see a noticeably faster load. For those running data centers, they will essentially double their capacity for running more applications or features.

Security Upgrades in PHP 7

There are still some serious issues with security, however. In their State of Software Security Report 2015, Veracode performed cloud-based scans and code analysis of more than 50,000 applications. They reported that approximately 86 percent of PHP applications showed evidence of cross-site scripting (XSS). Also, more than half (56 percent) appeared to have with at least one SQL injection bug. In part one of this series, we discussed how to handle both of those common flaws in PHP. Below are some of the significant security upgrades in PHP 7.

Whitelist Classes

The new filtered unserialize() feature is a more secure approach to unserializing objects in un-trusted data. You will be able to whitelist classes that can be unserialized to head off the possibility of code injections. This lets you pass complex data structures around as strings.

Cryptographically Secure Random Numbers

There are now two ways to generate both integers and strings. If you are coming from another object-oriented language, you may be thrilled to see these two.

string random_bytes ( int $length )


int random_int ( int $min , int $max )

These are useful any time that you need unbiased results. Also, if you are still running an earlier version of PHP, you can apply these functions with this userland implementation (for PHP versions 5.2 – 5.6).

Override Configurations

If you ever need to completely override session configuration directives in php.ini, you can now handle it with

bool session_start ([ array $options = [] ] )

The PHP manual explains:

“This creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie. When session_start() is called or when a session auto starts, PHP will call the open and read session save handlers.

The save handlers you use could be ready-built ones that were provided by default, or you could use PHP extensions like SQLite or Memcached. The other option you have is to use a custom handler that you would define in:

bool session_set_save_handler ( callable $open , callable $close , callable $read , callable $write , callable $destroy , callable $gc [, callable $create_sid ] )

Of course, the read callback here can retrieve any existing session data that is stored in a special serialized format. It will be unserialized and used to automatically populate the $_SESSION superglobal. That will be after the read callback returns saved session data back to your PHP session handling.

These are so important because custom save handlers give you more flexibility in what you do with the session data. For example, you can lower the risk of unauthorized use of a session by ending the session after a specified idle time.

Additional PHP Security Patches

In January, the PHP 7.0.2 update was released to address 31 reported errors and six of those were to seal off potential security vulnerabilities. At the same time, the older versions got updates too. PHP 5.6.17 addressed problems with 14 identified bugs, and PHP 5.5.31 was designed to close vulnerability loopholes. The developer announced that PHP 5.5 will be in security support mode from now until July 2016.

In terms of security, it is also critical to note that PHP 5.4 is no longer maintained, so if you are running that version, your site or application will be vulnerable to all kinds of attacks and exploits. Here are some of the potential attacks and remote code execution routines that the latest updates we designed to counter.

Buffer Overflows

PHP fixed a heap buffer overflow to prevent a hacker from passing a string longer than 1 billion characters to


The end goal is to overwrite the return pointer of the function. The hacker might then be able to change the flow of the code execution.

Memory Leaks

Another update addressed the memory read error in the GD graphics library. In the past, hackers could use this vulnerability to gain access to substantial and contiguous chunks of your memory. It works by passing a large number that exceeds the color palette array to ImageRotate.

Another potential memory leak that was plugged up was an error in FPM, the FastCGI Process Manager. In the older versions, whenever a long token like an HTTP request with an extra-long query string came at the end of the access.format option of FPM, the code would try to write outside the compiled buffer. PHP listed the severity as low because several other conditions would have to exist in addition before hackers could exploit this vulnerability.

Remote Code Executions

A potentially more serious threat was addressed by closing up the user-after-free vulnerability in WDDX, the Web Distributed Data eXchange interface. Hackers would have been able to remotely execute malicious code if this were still in place. Even when values are freed from memory during packet deserialization, malicious recordsets could gain use of the free memory.

Type Confusion

One update was targeted at eliminating type confusion vulnerabilities in WDDX. These left applications open to remote code execution attacks. Hackers would have been able to deserialize a string type and create their own hash table to insert.

Updates also addressed a second type confusion vulnerability in XMLRPC-EPI, which is the XML-RPC protocol for PHP. This would have left a door open for hackers to do a lookup on arbitrary memory addresses. That could lead to memory leaks or a complete crash of your PHP code.

What’s Coming Next for PHP

Adam Englander at LaunchKey made a significant prediction about where PHP might be headed in the very near future. Englander, speaking to other PHP developers at Reddit, said:

“You will start to see some movement into real hardware level Internet of Things (IoT) development in PHP. With a true asynchronous programming framework to take advantage of asynchronous I/O, you will now be able to write PHP applications to easily receive input from GPIO based hardware on Raspberry Pi, Intel Edison, and other IoT devices running Linux operating systems.”

It makes perfect sense that PHP will be looking for ways to expand its interoperability with other frameworks this year, and IoT is a field where a great of development is happening right now. As you may have noticed at CES this year, a host of consumer and professional markets are filling up with IoT devices and applications.

The problem is that security will need to get much tighter for PHP applications in IoT applications that interface with cars, automated door locks, location services, private identifying information and a host of other things that hackers will be extremely interested in accessing.

Getting the security piece right is incredibly important, and even more so, it is an enormous opportunity for any developers hoping to stay one move ahead of the hackers.

Just in case you missed anything, here’s a TL;DR for the entire blog:

  • PHP is super popular, running under around 82 percent of websites. That is why so many hackers want to break it.
  • PHP 7 just came out, the first major update in more than ten years.
  • You can now whitelist classes by unserializing untrusted data.
  • You can generate cryptographically secure random numbers
  • You can reset and override session configuration.
  • Patches addressed buffer overflows, memory leaks, remote code executions and type confusion vulnerabilities.
  • In the very near future, expect to see PHP working its way into the Internet of Things (IoT). That will issue in a new era of security concerns and advances.