Understanding and Implementing Website Security: Securing Drupal

Drupal Security Coverage

Drupal has a great Security Team and much of the security advice on Drupal.org is curated by this group. They provide security coverage for Drupal 7 and 8 core as well as all contributed modules and themes for Drupal 7 and 8. This is a huge amount of code to be responsible for and much of their work involves coordinating with and assisting module maintainers with security and security releases. They also maintain the procedures for reporting security issues.

If you are running Drupal 6, you should know that it’s no longer receiving security updates. As I’ve written elsewhere, you need a security plan for your Drupal 6 sites.  (tl;dr: contact Tag1 Consulting or myDropWizard and get covered.)

Secure Drupal Configuration

One of Drupal’s greatest strengths is its flexibility. Its rich permissions and configuration options make it possible to build a Drupal site where anonymous users can upload images, change files, edit the homepage, turn on modules, change themes and more. Of course, not many of us want to build that particular website, which makes configuring Drupal properly an essential part of securing Drupal. As the Drupal Security Report notes, “Incorrect use of core APIs and individual site misconfiguration is the cause of most vulnerabilities and weaknesses.”

Secure User 1

Drupal’s permissions system allows for very granular controls over who can do what. The first user created in Drupal has a User ID of 1 and is a special case. The code that checks to see if a user can do a particular action in Drupal starts off with an initial check: Is this User 1? If so, Drupal says “Yes”. (!) It does NOT stop to ask what the action is. User 1 can do anything.

As such, User 1 is a particularly important user to secure. If an attacker can gain control of User 1 or run XSS or CSRF attacks with User 1, your site can be completely compromised.

1. Don’t log in as User 1. Create unique users for every person who needs to login to your sites. Give them appropriate permissions. Don’t share the credentials for User 1 with others.

2. Don’t name User 1 ‘admin’. Many people name the first user ‘admin’. Don’t. There’s no reason to make it easier to guess for potential attackers.

3. Consider blocking User 1 on the live site. Drupal makes it possible to block users. Doing this on the production server can prevent potential problems. Note: Just block User 1, do not delete it, because Drupal uses User 1 for some operations.

Secure All Users

Of course, all users should be secured, not just User 1.

1. Use strong passwords. Every user, including User 1, needs to have a complex password. XKCD has good advice on strong passwords, and https://xkpasswd.net/s/ is an online tool that generates great passwords based on that advice.

2. Don’t share passwords. Sharing passwords across sites or with other people is a very bad idea. Don’t do it. Find a secure password management tool if you need one.

Secure Permissions

Drupal has a multitude of permissions that can be granted to different roles. An important part of building any Drupal site is spending the time to configure Drupal’s permissions as appropriate for your site.

1. Create different roles for different kinds of users. Give them only the permissions they will need. If you don’t know what a particular permission means, check the documentation for the module it corresponds to.

2. Pay particular attention to anything that starts with “Administrator”. Do not give those permissions lightly. Some of the “Administrator” permissions (e.g. “Administer Filters”) can be used to take over a site.

3. Test the roles on your site. Make sure that your users are able to do their tasks and nothing more.

Apply Security Updates

Drupal’s Update module has the ability to check for security, bug fixes and feature releases. Use it.

1. Turn on the Update module. Configure it with an email address you use and monitor. The module works by notifying you of security releases. You still need to apply them.

2. Know the schedule. Security releases come out every Wednesday for Drupal contrib and the third Wednesday of each month for Drupal core. Security releases happen between 12pm and 5pm Eastern Standard Time (GMT-5).

3. Hold time to perform security updates on Wednesday afternoons. If you are responsible for managing a Drupal site, make sure your Wednesday afternoons are clear so that you can handle any security updates that happen. If you’re not able to do this, consider hiring a firm to do so for you or subscribing to a service like Drop Guard.

Always Use HTTPS

Once upon a time, encrypting a site’s traffic via HTTPS was only common on sites handling financial transactions or potentially sensitive information. This is no longer the case. Google recognized HTTPS as a best practice back in 2014 and started giving an SEO boost to sites running over HTTPS. In late 2015 Let’s Encrypt started providing free HTTPS certificates to anyone, eliminating the cost barrier to install certificates. Many other services also provide HTTPS for free, including Cloudflare. Protect yourself and your users making sure all your traffic runs over HTTPS.

Use Secure Drupal Modules

One of Drupal’s greatest strengths is its huge library of contributed modules. There are tens of thousands of modules available, which makes finding and choosing Drupal modules a serious skill.

1. Choose Drupal modules wisely. Using Drupal is a fantastic book full of practical advice on how to build sites with Drupal. The Drupal 6 edition of the book came out many years ago but it’s excellent guide on how to select Drupal modules is still a great resource. Everything starting from “Assessing a Module’s Health” is still relevant today.

2. Do not enable the PHP module. Drupal 7 includes a PHP module that allows you to run arbitrary PHP code pasted into your website. There are many reasons that this is a bad idea, and Drupal 8 removed the module from core. You do not want Drupal executing untrusted PHP.

3. Use modules that improve Drupal’s security. There are a number of great modules that can make a Drupal site much more secure. Consider adding these to your sites:

   1. Password Policy and Password Strength allow you to enforce strong passwords on your sites.

   2. Security Review tests your site for many of the easy-to-make configuration mistakes that can make your site insecure.

   3. Security Kit (Seckit) provides various security-hardening options to mitigate the risks of application vulnerabilities like XSS and CSRF.

   4. The Hacked! module checks to see if any of the code running on your site has been altered in any way.

   5. Paranoia attempts to identify and block all the places that a user can evaluate PHP via Drupal's web interface.

   6. Permissions Lock  provides more granular control over what users with 'Administer Permissions' can configure.

   7. Login Security can limit the number of login attempts, deny access by IP address and notify administrators of brute force attacks.

   8. Automated Logout provides a site administrator the ability to log users out after a specified time of inactivity.

   9. Two Factor Authentication is a base module for providing two-factor authentication for your Drupal site.

[Related Offering] Pantheon Website Security Services

Secure Drupal Coding

If you write code for Drupal, make sure you know how to use Drupal’s APIs to write secure code. As we’ve covered previously, the OWASP 10 is an excellent place to start to make sure that you’re doing all the right things. Drupal Security Team members have given a presentation that covers all of the OWASP 10 and Drupal at a number of major Drupal camps and conferences. As we covered in Part 4 of this series, coders need to be especially aware of protecting against SQL Injection, XSS and CSRF.

Preventing SQL Injection

Drupal’s database abstraction layer handles SQL Injection. Use it properly and you’ll be safe. The short version—never concatenate data directly into SQL queries:

BAD: db_query('SELECT foo FROM {table} t WHERE t.name = '. $_GET['user']);

Instead, use proper argument substitution:

GOOD: db_query("SELECT foo FROM {table} t WHERE t.name = :name", array(':name' => $_GET['user']));

Preventing XSS

Preventing XSS requires safe handling of text. Drupal’s established pattern is to store exactly what a user has typed. This means that filtering is performed when content is output, not when saved to the database.

Greg Knaddison of the Drupal Security Team put together this guide long ago for knowing which filter functions to use in Drupal 7. I can no longer find it online, however, so I’ve reposted it here:

Image

Check_url, check_plain, check_markup and filter_xss are the tools you need in in Drupal 7.

Handling strings safely in Drupal 8 requires some different calls. Specifically, Html::escape() is for plain text, Xss::filter() for text that allows some HTML tags and Xss::filterAdmin() for text entered by admin users that can have most HTML.

Preventing CSRF

Preventing CSRF in Drupal is pretty straightforward. In general, it’s best not to take actions based on URLs (e.g. visiting example.com/node/75/delete should not delete node 75). It’s much safer to rely on form submissions for actions - especially those that modify data. Once again, details are slightly different in Drupal 7 and Drupal 8.

The Drupal handbook has good information on preventing CSRF in Drupal 7; the Drupal 7 Form API builds CSRF-safe forms. For URLs,  drupal_get_token and drupal_valid_token will generate tokens that can be used with regular links.

In Drupal 8, once again the Drupal 8 Form API will take care of forms. For tokens used on URLs, you just need to set _csrf_token to 'TRUE' on the route. For an example in Drupal core, see core/modules/shortcut.routing.yml:

shortcut.link_add_inline:
 path: '/admin/config/user-interface/shortcut/manage/{shortcut_set}/add-link-inline'
 defaults:
   _controller: 'Drupal\shortcut\Controller\ShortcutSetController::addShortcutLinkInline'
 requirements:
   _entity_access: 'shortcut_set.update'
   _csrf_token: 'TRUE'

Conclusion

Securing Drupal starts in the configuration. Adding modules to enhance Drupal’s security is a tremendous help. And, if you write code, make sure you know how to write secure code in both Drupal 7 and Drupal 8.