It has been a rough couple of weeks. First there was Shellshock, then AWS rebooting all instances because of a vulnerability in the Xen hypervisor, POODLE, and now a Drupal SQL Injection issue. This last vulnerability is unique in Drupal history because it is trivially exploitable and affects the integrity of all deployed Drupal 7 websites.
In preparation for this release, Moshe Weitzman from Acquia, David Strauss from Pantheon, and I, all three of us members of the Drupal security team, had a fruitful collaboration on how to best protect our customers. Moshe already mentioned this collaboration on the Acquia blog.
Our first instinct was to deploy some form of web application firewall to protect our customers. Unfortunately, along with the team at Acquia, we quickly came to the conclusion that there is no way to design a set of rules sufficiently broad to catch all possible attacks without also causing a significant amount of false positives.
Platform.sh, in addition to Drupal, runs a wide range of PHP applications. Our customers are leveraging Platform.sh to power development and production hosting of Drupal, Symfony, Pagekit, WordPress or even Magento projects.
So Platform.sh ended up with a unique approach: we deployed an automated protective blocking system. It works a bit like an antivirus: it compares the code you deploy on Platform.sh with a database of signatures of known security issues in open source projects.
This check is run every time you push code and also when the database of signatures is updated. For the few vulnerabilities deemed as highly critical, because they are remotely exploitable and affect the integrity of the whole application, we protectively block access to the application and inform our customers.
We were surprised that such a database of vulnerability signatures in open source projects does not exist yet. So we are going to reach out to multiple parties to see if there is interest in maintaining one in the open. Let us know if you want to collaborate on this.