Innovate faster and cut risk with PHP experts from Zend Services.
Learn PHP from PHP experts with free, on-demand, and instructor led courses.
Submit support requests and browse self-service resources.
This blog explains:
To better understand what security risks are and how they are handled, let's start with a definition of software security, by Gary McGraw:
“Software security is the idea of engineering software so that it continues to function correctly under malicious attack.”
In our context:
In engine development, we have a set of rules to determine what incorrect functionality could be defined as a security issue. Usually, it's a bug that can be triggered by a remote attacker to:
It is important to note that the purpose of this classification is to determine whether we want to handle the issue according to a special set of procedures defined below, but it does not reflect any opinion on the issue's importance.
Security issues are usually assigned a CVE identifier, which can be used to access a short description of the issue on software vulnerability catalogue sites.
The lifecycle of PHP security issues starts with the bug report, submitted either at bugs.php.net or at firstname.lastname@example.org. (Use Security classification if you submit a PHP security issue.) Once the problem is reported, we evaluate it according to the rules above. If it indeed reproduces and is classified as a PHP security issue, we start looking for the fix.
Most issues are fixed within weeks. However, some take days or longer, depending on the issue’s complexity. Once the fix is available, we contact the original reporter and ask them to verify the fix. This cooperation is very important. As open-source developers, our resources are limited, and we sometimes need help to cover all testing scenarios.
Once the fix is validated, the bug information and the fix are kept private under the release time. Releases happen every four weeks, and are announced at https://www.php.net/. Release notes include CVE identifiers assigned to security issues. Note that since CVE descriptions are kept secret until the release, it takes some time (usually several days up to a week) between the release and CVE descriptions being updated. You can always use full bug description and details in the PHP Bugs database.
There are several areas in the engine where common vulnerabilities and exposures appear more frequently. They have to do with:
PHP also relies on a number of third-party libraries — such as oniguruma, pcre, libgd — which can have security vulnerabilities. If the vulnerable library version is bundled with PHP on build, then the resulting engine build may be vulnerable too.
In some cases, the engine alone cannot ensure ample security under hostile attack. That’s why PHP developers need to take proactive steps to mitigate any security vulnerabilities. This includes risks from components — such as authorization, validation, whitelisting, OS permissions, and containerization — as well as attacks from the following vectors:
If you encounter a PHP security issue, first you need to know how bad it is by evaluating the following three dimensions:
If you are unsure whether a PHP security issue applies to you, it’s better to err on the side of caution and assume it does. This can save valuable time in patching the vulnerability instead of tracking down whether you use the specific module, function, or scenario impacted by the threat.
The criteria used to evaluate bug severity includes its prerequisites, complexity, and impact.
Which conditions should be true for the attack scenario to succeed? The more specific and uncommon prerequisites are, the lower the bug severity, and vice versa. For example, does the bug occur only when a specific:
How hard is it to perform an attack via this bug? The easier the attack, the more severe is the bug. For example, does the bug need:
What will the attacker gain with a successful attack?
Any PHP security issues can lead to one of the following consequences if not patched in time:
CVSS is the example of a formal system for evaluating issues according to the criteria in this blog. A best practice is to use it to evaluate all issues for the applications in your environment. It’s also important to note that evaluations are subjective on some levels. When it comes to severity, people must hypothesize about the possible actions of an attacker and their impact on a system.
The most basic thing to do to secure web applications against any engine vulnerabilities is to stay informed about all engine updates. You can start by:
The next step to secure web applications is to practice defense in layers, so that every aspect of your system plays its part in overall security. This includes your PHP code, PHP engine, operating system, and infrastructure.
Make sure that the data that can be maliciously manipulated is filtered, sanitized, and in the proper form. For example, URLs need to look like URLs. Emails need to look like emails. Numbers should look like numbers — and should be within sane ranges. PHP has a number of functions, such as filter extension. You should also follow industry best practices for secure PHP coding.
Use up-to-date versions and secure configurations. For example, do not output error messages to the user. Disable functionality you don't use such as unnecessary modules — or unnecessary functionality like file uploading if you don't allow uploading files. Configure reasonable limits for your applications including how much memory they can consume and how long requests should take. Monitor your system for violations of these limits because these metrics can suggest an attack is in progress.
Give your applications the minimal privileges needed for all tasks. For example, if your application only needs to read from the database, give it read permissions — but not write permissions. If it only needs to read certain files, ensure the application cannot write to them. Limiting access privileges will limit the impact of any vulnerability.
Assign restrictive permissions to processes executing your application, so they only can access what they need.
Use containers, firewalls, and other technologies to ensure minimal impact of any potential vulnerability.
For more information about PHP security issues and how to secure web applications, watch my video on PHP engine security.
Stanislav Malyshev (AKA Stas) has been developing software for almost three decades, and has been an active member of the PHP community since 2000. He has contributed to many parts of the PHP core, was a release manager for the PHP 5.4 branch, and served as the co-release manager for PHP 7.3. Stas has also worked on PHP-related projects including Zend Framework (which is now called Laminas) and Zend Server. When it comes to PHP, his current focus is improving security-testing and reporting processes.