Since its initial release in December 2015, PHP 7 has earned praise by early adopters for its new language features and impressive performance improvements. But developers beware: Glaring security holes lurk beneath the glamour of a new release. In late December 2016, security researchers discovered multiple zero-day exploits in PHP 7, including remote code execution and denial of service vulnerabilities. Attackers can use these exploits to take your site offline or worse—hijack your site for all manner of dastardly deeds.
While the latest PHP 7 releases include patches for these vulnerabilities, the Common Vulnerabilities and Exposures (CVE) List shows that security researchers regularly discover PHP security flaws. In this post you will learn how security breaches can impact your business and what you can do to protect your PHP applications from hackers.
Now that we understand the consequences of a security breach, let’s take a closer look at the zero-day exploits discovered in PHP late last year.
The common denominator among all three exploits is PHP’s unserialize() function. PHP 7 introduced a new filtered unserialize feature that aims to mitigate the impact of code injection vulnerabilities by requiring developers to whitelist classes that are safe to unserialize. But even with this improvement, passing untrusted input to unserialize() is not safe, as clearly indicated by the function’s documentation.
What is untrusted input?
Any input that comes from a source not directly under your control should be considered dangerous. Examples of input sources include query string parameters, HTML forms, file uploads, third-party APIs, and more.
Is my site vulnerable?
The only way to know if your site is vulnerable is to inspect your entire codebase and all of its dependencies. Typically the vulnerability report, such as this one for CVE-2016-7479, includes enough information for you to identify vulnerable code. However, each vulnerability is unique, making it unfeasible to manually inspect your codebase for every possible vulnerability—not to mention you have to repeat these inspections every time you change your code or new vulnerabilities are discovered.
How do I fix it?
The immediate fix is to update to the latest patched version of PHP 7. If that’s not possible because you are using shared hosting or because upgrading could break your application, you need to implement a workaround. Even if you can upgrade PHP, you should still consider a workaround because unserialize() is historically risky and likely still contains undiscovered vulnerabilities. In this case, the safest approach is to use an alternative serialization format, such as JSON, that can deserialize data without loading or executing additional PHP code.
At this point your head may be spinning—and we’ve only covered a single PHP 7 vulnerability. Fortunately, there are many industry standard tools and practices available to help you make your site more secure without losing sleep or breaking the bank. Even adhering to only two or three of these recommendations will put you in a more secure posture than many organizations.
This one isn’t PHP specific, but if you don’t keep your operating system and PHP version up to date with the latest security patches, nothing else you do matters. Most Linux distributions include PHP in their package repository, and they update it regularly with the latest security patches. Enabling automatic security updates for your OS is the absolute minimum you can do. If you install PHP from source or some other method, you should use configuration management software such as Ansible, Chef, or Puppet to automate the installation and upgrade process.
Most production PHP applications depend on dozens of third-party libraries directly, and even more libraries indirectly. Each one of these components may have security flaws and require regular updates. For this reason, many development teams use Composer to simplify management of their app’s dependencies. But how do you know when you need to update?
Unless your application lives in a vacuum, you will make code changes on a regular basis. Any developer involved with building or reviewing PHP applications should have a basic knowledge of common web application vulnerabilities and secure coding practices.
Understanding the OWASP Top 10 is a good foundation for general web application security knowledge. Attack vectors such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) are common to web applications written in any programming language.
The next level of security knowledge is to know the specific security considerations and concerns for the PHP language. There are good online guides available to get you started, and the PHP manual itself has an entire section devoted to security.
Static analysis tools read and analyze your application source code, looking for common security vulnerabilities and insecure code structures. For example, the Exakat PHP security scanner can identify unsafe use of the unserialize() function that we examined earlier. Drawbacks of static analysis tools include incomplete rulesets and false positives. There are many open source and commercial PHP static analysis tools available, so do your homework and find ones that work well for you. While they often provide quick and useful feedback on the security of your code, static analysis should never be used as your only security control.
While static analysis tools examine your application’s source code, dynamic analysis tools, such as Arachni or the OWASP Zed Attack Proxy, observe the behavior of running applications. These tools crawl your site, click on links, fill out forms, and do all kinds of unexpected things to your site in order to discover classes of vulnerabilities that can’t be detected using static analysis. If at all possible, you should run these tools against a test instance of your application and not a production site, because they can potentially modify data or break your site.
Good PHP application security takes time, requires expertise, and demands a broad toolset. If you don’t automate the basics and make security visible, your team will inevitably drift back into poor security habits. One of the best ways to establish a sustainable application security baseline is to integrate security controls into your continuous integration pipeline. Many of the security tools mentioned previously have scriptable command-line interfaces, and some even have first-class CI support, such as the OWASP dependency-check and ZAP plugins for Jenkins.
When developers notice security issues in their build status reports, they will naturally start fixing them as part of their daily work. Advanced teams will even fail the build when a security check fails, preventing deployment until they can patch the issue. Instead of taking weeks, months, or even years to detect and remediate most security vulnerabilities, you can have a Zero mean time to remediation (MTTR). You can find and fix security problems before unleashing your code on the internet.
What about application security problems that arise in production? Despite your best efforts to build security into your product, there will always be opportunities for attackers to exploit your application in the wild. While advanced security monitoring and incident response are beyond the scope of this article, one simple solution that offers substantial security benefits is to use a web application firewall in front of your site.
Web application firewalls (WAF) stop malicious requests before they can reach your servers. Not only can a WAF prevent common types of attacks, it can also block traffic from sources known for malicious activity. Most commercial web application firewalls act as a reverse proxy and require little to no application or hosting changes to start using. ModSecurity is an open source WAF module you can install on your Apache, Nginx, or Microsoft IIS web server. With the modern increase in threat activity and rise of massive botnets, leveraging a WAF is quickly becoming a requirement for site owners.
Security vulnerabilities are a fact of life. While a security breach can be damaging to your business, there are plenty of ways you can protect your PHP sites and mitigate your risk that don’t require you to be a security genius. Don’t let the recent discovery of PHP 7 security vulnerabilities discourage you from using the latest and greatest version. With the right training, awareness, tools, and practices, you can safely run PHP 7 applications in production today and in the future.