Testing for PHP Composer security vulnerabilities with Snyk
DeveloperSteve Coochin
May 20, 2021
0 mins readPHP is used extensively to power websites. From blogging to ecommerce, it’s embedded in our everyday lives and powers much of the internet we use today. According to a Wappalyzer report on top programming languages of 2020, PHP has a 79% market share of backend languages used on the internet today.
One of the biggest challenges with PHP libraries over the years has been package management. There have been a few ways to easily install and maintain libraries including PECL, CPAN. Special mention to PEAR which was introduced in 2009 became one of the first ways to load and distribute libraries, this later became PEAR2 which eventually became part of PHP Composer (now in its 9th year!) which is what we are going to look at today.
What is PHP Composer?
PHP Composer is a package management tool used to install and update libraries and dependencies in PHP. It gained popularity quite quickly because of the way it loads and maintains libraries and dependencies within frameworks and projects. Driven by the command line, it allows for users to install PHP applications, libraries, and dependencies — with autoload capabilities — within projects. It’s important to note that PHP Composer will not install anything globally.
Let's look at PHP Composer security
While PHP Composer makes app development faster, it does abstract away a level of control and visibility. So while it makes coding easier, it does beg the question… is it doing it safely? With Snyk, I’m able to answer that question in a few clicks.
Before we take a look at a few platform implementations of PHP Composer in the wild, I just want to point out a few things.
As a user/developer of these platforms, my findings were surprising for a variety of reasons. This reinforces the idea that continually building awareness and education is paramount for developing securely.
In all the below instances, I have reached out to discuss the vulnerabilities with each community and raise awareness when not already known to them (many already had fixes).
Kirby
To get started with Kirby and Composer, you can follow the simple setup instructions within the Kirby meets Composer documentation:
Composer installs the latest version of Kirby (3.3.5), which in the Snyk Vulnerability DB only has one medium and one low severity vulnerability. However, the Snyk CLI finds a problem with one of the dependencies, namely PHPMailer which uses version 6.2.0. This version of PHP Mailer shows up as having a high severity vulnerability for cross site scripting.
This is fixed in PHPMailer 6.4.1 (at the time of writing), and can be fixed by running composer upgrade to the latest version. Looking back through the history of the module shows a long history of vulnerabilities. Which is why regular scanning with Snyk Code is highly recommended to be alerted if new vulnerabilities are discovered.
Joomla
The Joomla repo comes with a Composer file that installs all of the dependencies needed for it to be run. Running a scan using the Snyk CLI, we find 2 issues and 4 vulnerable paths.
In particular we again find PHP Mailer, which installs version 5.2.28. This version has the issue of improper input validation, and Snyk tells us that it is fixed in version 6.1.6.
Snyk also discovered a man-in-the-middle (MITM) vulnerability, which is being loaded in via `paragoine/random_compat` in version 1.4.3 and is associated with `joomla/session`. MitM attacks are extremely bad, as they allow electronic eavesdropping. To learn more about this kind of vulnerability, check out our man-in-the-middle attack blog.
Drupal
Using the handy guide in the Drupal repo, we can get up and running quickly using the latest 9.x dev branch.
While the installation is running, we can check for any known issues in the Snyk Vulnerability Database, which also shows Drupal version history vulnerabilities to watch out for. Then, using the Snyk CLI, we can see that 9.x comes back green. And just to be extra safe, we can do the same with Drupal 8.x, and see that it also comes back green. Great!
Now that those two versions are cleared, let’s also run a check of Drupal 7, as it is still used a fair bit. To do this, clone the Drupal 7.x repo.
Scanning against 7.x, the Snyk CLI results are a little different, showing 9 vulnerabilities and 18 vulnerable paths. Everything from file upload exploits through to DoS, remote code execution (RCE), and arbitrary code execution (ACE).
Based on these findings, I would recommend upgrading to 8.x at a minimum to keep your Drupal implementation secure.
Help the communities by contributing back
When I first started running tests on some of these commonly used platforms I actually didn't know what I would find. And as I said before, the results were quite surprising. For the unsuspecting developer, team, or company using these platforms in production, they may not be aware what exactly is being let in. Hopefully this blog helps more teams stay safe.
But I’m just one developer and this is just one blog. For us to really make a big security impact, I’d encourage you all to test projects yourself and contribute to the fixes. These are amazing communities quite often run by passionate developers who want to build things used to help people the world over and they need your support.
Get started in capture the flag
Learn how to solve capture the flag challenges by watching our virtual 101 workshop on demand.