Greg Knaddison has worked for big consulting firms, boutique software firms, startups, professional service firms, and former Drupal Security Team leader. He is currently the director of Engineering at CARD.com and a Drupal Association advisory board member.
Michael Hess works with the University of Michigan School of Information and the UM Medical Center teaching three courses on content management platforms and overseeing the functionality of hundreds of campus websites. He serves in a consulting and development role for many other university departments and is the current Drupal Security Team leader. He also consults with BlueCross on large-scale medical research projects. Hess is a graduate of the University of Michigan School of Information with a master's degree in information.
Greg Knaddison (left) and Michael Hess (right)
Prior to their DrupalCon 2015 talk, I caught up with Greg and Michael to discuss managing security advisories from external libraries, plans for automated security updates, code reviews, what to expect in Drupal 8, as well as, any advice they had for newcomers to Drupal.
How do you manage security advisories from external libraries incorporated into Drupal?
We have two strategies. First, our general policy is that third-party code should not be included directly into the Drupal.org repositories, so our advice since 2011 is that individual site owners should be aware of their own updates to third-party code. One thing that Drupal module maintainers can do is add a hook_requirements to check if the installed version of the external library is insecure and then show a message to the site admin letting them know to upgrade.
Second, when exceptions are made (e.g. Drupal core), we work with the authors of the libraries to fix issues and coordinate releases. For example, we have a working relationship with the Symfony project's security team to fix issues in a coordinated manner. Since Drupal 8 is not yet generally available, we don't include any security advisories for issues in Symfony just yet, but we will as soon as Drupal 8.0.0 is released.
Are there any plans for automated security updates in Drupal?
It is something the community is talking about. Of course, by automating security updates you add a different set of risks. Updating Drupal code sometimes requires manual changes and that can not be done via automation. We as a community continue to explore this.
Some alternative solutions exist to achieve that goal in ways that might be more secure and reliable. For example, some of the Drupal-focused hosting companies incorporate features into their hosting plans that make it very easy to test and deploy security releases. There are also consulting companies who can be hired to monitor the security releases for you and update your site. And a relatively novel solution is Drop Guard, a rules-based third-party service that integrates with existing hosting and deployment tools to automated security updates. For more details comparing these hosting companies and service providers, see this Wiki page list of service providers who keep Drupal sites up to date.
For those interested in building something similar for themselves who are running an unmodified version of core/contrib; and who are comfortable with a little shell scripting, just do drush up -y inside of a cronjob. An obvious improvement would be to do that same drush up -y inside of a test environment, run automated tests, and only deploy if the tests pass.
What are your thoughts on automated code reviews and penetration testing?
Automated code reviews based on the Coder module will be enabled for all projects some time this year. However, it will only catch some of the most common issues that are easily found with pattern matching. It will miss more complex and potentially more damaging issues. Broadly, we hope this integrated code quality check will reduce the number of security issues in modules hosted on drupal.org (making the project safer and reducing work for the security team). We're excited to see what improvements will be made to Coder once it's more tightly integrated to drupal.org.
Automated penetration testing results tend to include a lot of false positives and miss real issues. The Drupal Security Team gets PDFs emailed on a regular basis showing the results of popular tools and, so far, I haven't seen one that I really loved. That said, they are often a cost effective tool as part of a more complete audit.
The most valuable results come from a in-depth review from an expert who reads the code, understands the purposes, uses a reproduction of the real site, and can provide advice on how to fix or mitigate the issue.
What new security features can we expect in Drupal 8?
This is a topic we plan to cover in depth during our session Building secure sites with Drupal at DrupalCon Los Angeles.
Drupal 8 will use a template language called Twig that replaces the Drupal-specific PHP template system. This means that we don't have PHP code in templates. Twig also provides an auto-escaping feature to prevent XSS vulnerabilities in themes.
In Drupal 7 and before, manual integrations of third-party WYSIWYG on many sites allowed the untrusted content editors to to use the "full HTML" text format, creating a cross site scripting vulnerability. In Drupal 8, WYSIWYG is built in with good defaults in a way that keeps the WYSIWYG buttons in synch with the input format. This decreases the likelihood of a site builder accidentally using the Full HTML text format to "make things work" and introduce a vector for XSS.
The PHP module has been removed from core. There were two big motivations for this change. First, this module makes it just a little too easy for a site admin to mistakenly open PHP execution to untrusted users. Second, if an attacker were to gain access to an administrative account (by sniffing sessions or guessing a weak password) then the attacker could use the PHP module to execute arbitrary PHP code. Drupal 8 sites will have fewer potential ways to be compromised.
Drupal 8 has CSRF tokens built in to the routing system for Drupal 8. Ever since Drupal 4.6, there have been simple functions for preventing CSRF: drupal_get_token and drupal_valid_token. Those functions are still available in Drupal 8 if some code requires it, but now it's even easier to protect a URL from CSRF: the declaration for a route includes a parameter saying whether it should be protected or not—very easy.
What advice would you give new site owners implementing a Drupal project with regards to security?
Keep your site up to date. Subscribe to the security advisories RSS and mailing list or follow @drupalsecurity. Security releases are made on Wednesdays, so make sure your team has a plan and time allocated for doing security upgrades after the site is live. Check your permissions page and consider using a tool like Security Review to audit your site's configuration.
And, of course, there are dozens more little things that we'll cover at our session, Building secure sites with Drupal at DrupalCon Los Angeles. If you can't make the event directly, video will be posted to the site shortly after the event.
Speaker Interview
This article is part of the Speaker Interview Series for DrupalCon 2015. DrupalCon 2015 brings together thousands of people from across the globe who use, develop, design, and support the Drupal platform. It takes place in Los Angeles, California on May 11 - 15, 2015.
Comments are closed.