C H A P T E R  6

Security in Drupal

byStéphaneCorlosquet

“Security is a process, not a product. Products provide some protection, but the only way to effectively do business in an insecure world is to put processes in place that recognize the inherent insecurity in the products.”

—Bruce Schneier

The Internet is rife with spammers and hackers threatening to deface or take down your site, ruin your brand, paralyze your community, or steal confidential data. Whether you are a site administrator, module developer, themer, system administrator, or user, you ought to bear security in mind when administering your site or writing code. You could put your own site or other people's sites at risk if you don't follow some simple rules and best practices. Fortunately, you are not alone in this situation, and the Drupal community has developed a solid process to help you avoid major headaches when dealing with security matters.

Setting Up a Secure Drupal Site

Let's start off with the good news: Drupal is configured to be secure out of the box! This is because it adopts fairly conservative settings by default. You will most likely want to change these settings to extend and tweak your site to your needs, and that's where you run the risk of opening some doors for unwanted visitors to damage your site. However, you're in good hands: with its improved user interface, Drupal 7 will often warn you when a setting could have an impact on security. Don't just rely on it, though; exercise common sense, and read on to know the common pitfalls of misconfigured Drupal sites.

Use Strong Passwords

This advice is true for any system using passwords for authentication: you must use a strong password (see Figure 6–1). Anyone who knows your password can log in and perform potentially damaging actions on the site. This is especially true for the user id 1 or any other account with elevated permissions.

Figure 6–1. Use a strong password to keep your user account safe.

But what makes a password strong?

The article at www.baekdal.com/tips/password-security-usability demonstrates that having a three-common-word password is 10 times more secure than a regular one-word password. (Drupal passwords can contain spaces, by the way.)

It's also important to avoid sharing your password with anyone. Likewise, don't create accounts shared among users for site management and moderation purposes. If a group of users needs to perform similar actions on a site, create an account for each user and grant them the same role(s); this will make it easier to track who did what.

Your account will also be linked to an e-mail address. While you're at it, make sure you trust your e-mail provider and have a strong password there, too; if your e-mail account is compromised, your Drupal account password can be reset in a few seconds, defeating the effort you put into creating a strong password.

Reserve User 1 for Administration Purposes Only

The first user created during the installation process is given permission to do everything on the site, always. Therefore, it's considered best practice to reserve this user not as one's own personal account, but as a superuser or superadmin account. (Drupal requires account e-mail addresses to be unique, so if you have only one e-mail address, it's better to make the first account your own than to have an account with a broken e-mail address. Note, however, that some e-mail services allow you to use variant addresses: for instance, [email protected] will receive e-mail sent to [email protected], and Drupal will accept the latter as a separate address.)

Be Cautious When Assigning Permissions

Each user can be given a set of roles, and each role includes a set of permissions. While some permissions are fairly benign, such as View published content, others can have dramatic consequences. Generally, permissions starting with “Administer” should only be granted to highly trusted users. Others, like Bypass content access control, can give the ability to view, edit, and delete any content: this can lead to information loss if granted to a careless user. Drupal 7 highlights these permissions with a warning indicating they should only be given to trusted users, as shown in Figure 6–2.

Figure 6–2. Some permissions have security implications and should only be granted with care.

Beware that the Authenticated User role is given to any user able to log in to your site unless their account has been blocked. By default, Drupal is configured to require administrator approval for new accounts, but if you have changed this setting at admin/config/people/accounts to allow visitors to register accounts without approval, you should review what permissions the Authenticated User role has and ensure they are all safe. Failure to do so could lead to unintended consequences, like a flood of spam on existing nodes since the Post comments and Skip comment approval permissions are both granted to the Authenticated User by default.

Keep Text Formats Tight and Secure

User input is evil and should never be trusted. With the exception of a few places like the e-mail address where user data is validated on input, Drupal sanitizes user submitted data on output. This has the advantage of preserving user input data so that it can be escaped properly depending on which context it has to be rendered. See the excellent article by Steven Wittens on “Safe String Theory for the Web” at acko.net/blog/safe-string-theory-for-the-web for an in-depth explanation of this design choice. Thus, failure to escape any user submitted data can lead to the one of most common web application vulnerabilities: cross-site scripting (XSS)¹. Drupal uses text formats when displaying a piece of content submitted by a user in a text field (e.g., the body of a node), for example. Each text format contains a set of filters that will escape content and make it safe for display in a given context. By default, the text formats Filtered HTML and Plain Text are safe, which is why they can be both used by anonymous users and authenticated users. Be cautious if you change the settings of these text formats; they can become unsafe if misconfigured. The Security Review module² makes it easy to check text format configurations.

Avoid Using the PHP Filter Module

Although it's handy to be able to write PHP code directly into your Drupal web interface without having to create a module, it's also very dangerous! All PHP code should live in the form of modules or themes. Writing PHP in Drupal's web interface is a bad idea for the following reasons:

• It's unfriendly to edit and debug (no syntax highlighting and no proper error reporting).
• It makes code reviews difficult and versioning impossible.
• A trusted user might inadvertently damage your site with malformed PHP code.
• If your site was to be compromised, a hacker could penetrate and damage your server using well-crafted PHP code. Keeping the PHP Filter module turned off (or even better, removing it entirely from the filesystem) could help contain such intrusion to the Drupal level only.
• In terms of performance, storing PHP code in the database will prevent any opcode caching mechanism from working on this piece of code

Note that some contributed modules might offer a functionality similar to that of the PHP Filter module; they will suffer from the same flaws noted previously. Also, be careful when using PHP snippets found on drupal.org or elsewhere: make sure you understand what they do and how they can affect your site. Many of these snippets have not been reviewed from a security standpoint and might expose your site to vulnerabilities. Code snippets are also generally less reliable than code found in a module.

Security Process

As a site administrator, security is not just something to consider when setting up your site. The Drupal core project maintainers can only go so far as to release software with no known security holes on the day of the release. However, that does not guarantee that there will never be any security problems in the future. Things evolve quickly on the Web, and new security vulnerabilities and techniques are discovered frequently. They might not be specific to Drupal and might impact any we6–based system.

The Drupal Security Team is a group of volunteers with an interest in keeping Drupal secure by helping both site administrators and developers understand how to avoid security issues on their site and in their code. The first goal of the Drupal Security Team is to help resolve security issues in Drupal core and contributed modules. All issues reported to the Security Team are first discussed privately with the reporter and the project maintainer until a solution is found and a fix is made to the code repository. The Security Team coordinates Security Advisories (SA) in release cycles, usually on Wednesdays. Each SA has a unique ID including its type and year. There are three types of advisories.

• Drupal Core security advisories (e.g., SA-CORE-2010-002) are the most important type of advisories as they concern every Drupal site. Updating is strongly recommended.
• Contributed projects security advisories (e.g., SA-CONTRI6–2010-015) are the highest volume type of advisories published by the Security Team. Each advisory refers to a particular contributed project (or sometimes several of them), and site maintainers should carefully evaluate whether any of the sites they maintain are affected and update them appropriately.
• Public service announcements (e.g., PSA-2011-001) aim at educating the community and contain general security-related information such as security policy changes, recent threats, or social engineering attacks that don't affect any particular module but are nonetheless relevant to site administrators and developers.

Security advisories and announcements are communicated publicly through the following channels:

• Drupal.org security announcements listings at drupal.org/security
• RSS feed for each listing:
  • Core: drupal.org/security/rss.xml
  • Contrib: drupal.org/security/contrib/rss.xml
  • Public service announcements: drupal.org/security/psa/rss.xml
• E-mail via the Security Announcements mailing list; all three types of announcements are included. You can subscribe in the “My newsletters” tab when editing your profile on drupal.org.
• Twitter: twitter.com/drupalsecurity

All security advisories include steps to resolve the security vulnerability at hand. In most cases, it will be a link to a security release for site administrators to update their site. In the rare case when project maintainers are not responsive or available to fix the issue, the Security Team might advise to turn off a particular module. PSAs include more general advice on security best practices.

Choosing Modules and Themes: How Secure Are Contributed Projects?

Each line of code in Drupal core goes through a rigorous peer review process before it is committed to the code base; even after being committed, this code is continuously audited by hundreds of contributors due to the nature of open source software. Several thousands of contributed projects are available for free on drupal.org. The Drupal community tries to find the right balance between keeping a low barrier of entry for new contributors and accepting code that is clean and secure, but a growing community and only a handful of volunteers monitoring this growth in terms of code quality makes the task very difficult. The consequence is a varied level of quality of code in the land of contributed projects. However, code found on Drupal.org is more likely to be of higher quality than code found elsewhere outside Drupal.org, since the community tends to scrutinize code on Drupal.org more than anywhere else.

As a site administrator looking at installing a module or a theme on your site, you are responsible for evaluating the quality of a project from a security standpoint. Neither the Drupal community nor the project maintainer can be held responsible for any damage done to your site, whether the damage is done during the installation or later on due to a security bug.

Assessing the value of a project is a somewhat subjective task. Each of the criteria in the next sections will not give you the complete picture when taken on its own; hopefully, by combining them you will be able to make an educated decision when choosing contributed projects for your site.

Project Home Page

A project home page includes a lot of useful information to assess the health of a project. These elements will help you in your evaluation. An example of contributed project page is drupal.org/project/views. Figures 6–3 and 6–4 contrast an abandoned project with a well-maintained project.

• How reputable are the maintainers? You can find the list of maintainers as well as their activity on the right-hand side of the project page. If you don't know a maintainer, look up his profile on drupal.org to see his participation in the community; he might maintain other modules that you might know or use. It's a good sign if the project in question has a reputable maintainer with fairly recent activity.
• How active is the module development? Is the module abandoned or seeking a new maintainer? This information is available on the project description page (see the example of an abandoned and obsolete module in Figure 6–3). Modules falling under these categories are not likely to receive any attention in the future and might contain security vulnerabilities. Although the Drupal Security Team will generally add a warning message on the description of projects that are abandoned and known to contain a security vulnerability, the absence of such message does not mean that an abandoned project is safe to use.
• Popularity: Check how many sites report using a project in the “Project Information” section shown in Figure 6–4. The more sites using a project, the more likely it has been reviewed and is trusted.
  

  Figure 6–3. The Project Information section of an abandoned project

  

  Figure 6–4. The Project Information section of a well maintained project

• Releases: Avoid using development releases on production web sites. Pick a stable release if one is available for your Drupal version. Unstable, alpha, beta, or release candidate releases can contain security bugs, which are generally discussed publicly. If you make the decision to use such modules on your site, be sure to know what these bugs are and take the right measures to protect your site.
• Does the project have known security bugs? The issues block located on the right hand side of each project's home page shows some statistics on the issues and bug reports on the project (see Figure 6–5). Click on the number of open issues to view an exhaustive list of issues, as shown in Figure 6–6.
• Check the issue queue to see what pending outstanding issues have been reported so far, and whether some of them have an impact on security. Looking at the last updated column in the issue queue will give you a sense of how active a project development is (see Figure 6–6). Seeing issues with the status of Fixed is a strong indication of a well-maintained project. You might want to use the filters at the top of the list of issue to narrow down your search on a particular version of the module or on a particular type of issue, such as bug reports.

Figure 6–5. Click on the number of open issues to browse the issue queue

Figure 6–6. An active issue queue is the sign of a healthy module.

Security Code Reviews

What do you do if you've found a contributed project that matches your needs but you have doubts about its level of security? It might not have reached a stable release yet, or your department might require that any code be security reviewed prior to being used.

If you're a developer, the Coder³ and the Secure Code Review⁴ modules will be of great help at identifying pieces of code that do not comply with Drupal security standards. While these modules are quite good for a first pass at a security review, they can't guaranty that a module is secure, and they don't replace the eyes of a security expert.

If you would rather hire skilled consultants to do code reviews, several Drupal shops specialize in this area of expertise, most notably Drupal Scout (drupalscout.com) operated by Greg Knaddison and Ben Jeavons, both members of the Drupal Security Team.

Keep Your Code Base Current

Configuring Drupal properly is only the first step towards a secure Drupal site. Dynamic web applications like Drupal can't be left unmaintained on the Internet where new threats and exploits are discovered every day. It is a mistake to think that once you've built a site and pushed it to production, you can just leave it there and not worry about it. Just as you monitor your server performance or maintain your software stack, you will want to run the latest version of Drupal core and its contributed modules. Fortunately, the Drupal community has a very good infrastructure that helps site administrators know when they need to upgrade a given module.

Drupal core ships with the Update Manager module that will warn you when new security releases are available for your installed modules. You will see a red warning message in the administrative area encouraging you to update your modules. An e-mail notification is also configured by default. You can view the list of available updates at Admin Report Available updates (admin/reports/updates). Any security update will appear with a red background, as depicted in Figure 6–7.

Figure 6–7. The Update Manager module shows available updates for installed modules and themes. It is strongly recommended that you update any module with a security update.

Updating a module or theme is very easy with the tools available for Drupal. The core Update Manager module lets you to update any module via the web interface. You can also use Drush⁵ or update the code manually by downloading the tarball from the project download links or via git. See Chapter 7 for more detailed information on how to update Drupal.

Writing Secure Code

Drupal offers great APIs for module and theme developers. As long as these APIs are used properly, writing secure code for Drupal is easy, even with little knowledge about security. There are, however, some basic rules to keep in mind. The first rule is to use Drupal's APIs as much as possible and use them properly, even if they do not seem to make sense; there is generally a reason for using them. Here are a couple of examples:

• When displaying a link, it might be more intuitive to build the HTML string by concatenating the <a> and href elements, but this can introduce a cross-site scripting vulnerability if the input is not trusted. By using the link function l()⁶, you save yourself some headaches since Drupal will take care of the proper escaping for you and will also filter for malicious protocols.
• Form API: You should never use data straight from the $_POST variable, but instead rely on the Form API validation and submit functions which prevent cross-site request forgeries⁷.
• Database API: When writing SQL queries, it's tempting to use PHP variables directly in the SQL query. That can create a SQL injection⁸, and it can be avoided with proper use of the Database API⁹.

There are many more examples where the Drupal framework prevents security vulnerabilities. Here is a list of helpful resources for developers willing to learn more about security in Drupal:

• Publications:
  • Greg Knaddison, member of the Drupal Security Team, wrote the only book to provide a deep dive into security in Drupal: Cracking Drupal: A Drop in the Bucket (Wiley, 2009), crackingdrupal.com
  • The Drupal Security Report was written by Ben Jeavons and Greg Knaddison. This is a useful document for decision makers and people interested in understanding how Drupal has been handling security in the past. drupalsecurityreport.org
• Online resources:
  • Get familiar with Drupal's APIs at api.drupal.org where all Drupal functions and APIs are documented. Notes on security are included where relevant.
  • The Develop for Drupal handbook gives a higher perspective on how to leverage Drupal APIs at drupal.org/documentation/develop
  • The “Writing Secure Code” section of the Develop for Drupal handbook gives a series of examples with code snippets on how to use Drupal APIs in a secure manner at drupal.org/writing-secure-code
• Security blogs:
  • Heine Deelstra, Drupal Security Team lead, blogs about security in Drupal at heine.familiedeelstra.com
  • Greg Knaddison and Ben Jeavons write about security at crackingdrupal.com/blog
  • DrupalScout is building a Knowledge Base on security at drupalscout.com/knowledge-base

Dealing with Security Issues

The Drupal Security Team has a process for dealing with security issues found in the contributed projects hosted on drupal.org. As a developer, if you come across some piece of code that appears to contain a security vulnerability, you should know how to deal with such a situation.

You Found an Issue in Drupal core or a Contributed Project

The process is detailed in this section; note, however, that this process could change in the future, so check at drupal.org/security-advisory-policy for current information on the Drupal security policy.

First, make sure the code is hosted on drupal.org; the Drupal Security Team does not deal with code hosted elsewhere. Secondly, if the questionable code has not been released as part of a stable release (in other words, it's in a development snapshot, alpha, beta, or release candidate release), you are encouraged to discuss this issue publicly in the issue queue. If the code has been released as part of a stable release (e.g., 7.x-1.2), you should not discuss this vulnerability publicly, unless it requires one of these permissions to be exploited:

• Administer filters
• Administer users
• Administer permissions
• Administer content types
• Administer site configuration
• Administer views

Any user with any of the above permissions can already do a lot of damage to a site, so it is expected that only trusted users would be granted these permissions, and therefore it is fine to discuss these types of issues publicly. Please check drupal.org/security-advisory-policy for the current policy, which might change over time.

In any other case, don't discuss your findings publicly, but instead contact the Security Team by e-mail at [email protected] and explain in detail how to reproduce the issue and what version of Drupal core, modules, and themes you are using. The Security Team will investigate the issue and work with the project maintainer to create a fix, patch the code, create a release, and announce the release. You will be credited in any announcement made about this issue. At the time of this writing, issues should be reported to the Security Team by e-mail; however, this is likely to change in the future, so please check drupal.org/node/101494 for current information on how to report an issue to the Security Team. Make sure to subscribe to the security mailing list to be notified of any change (see the beginning of the “Security Process” section).

Fixing a Security Issue in Your Project

If you find a vulnerability in one of your projects, contact the Security Team before doing anything about it. If the Security Team receives a report about a vulnerability in one of your projects, you will be contacted privately by e-mail. As a project maintainer, it is your duty to collaborate with the Security Team in order to keep the vulnerability secret until a fix is made available to the public. You will be invited to send a patch fixing the issue so that the Security Team can review it and possibly suggest a better way to solve the issue. When the patch is ready and has been approved by the Security Team, a date will be chosen for the patch to be committed and a security release to be published. You will be asked to help draft a Security Advisory (SA) for your project to be sent out on the day of the security release. Security releases usually happen on Wednesdays. You will be invited to commit the patch and push the fix to the drupal.org repository as soon as 24 hours before the agreed release date. Then you will be able to create a new release for all the branches that were affected by the vulnerability and tag it “Security update,” as shown in Figure 6–8. Send the links of the releases to the Security Team so they can add them to the SA. The releases will remain unpublished until the Security Team publishes them and sends the SA at the same time.

Figure 6–8. The Create Project release form on drupal.org. Make sure to tag your release as “Security update” if it includes security fixes. You should already have contacted the Security Team at this point!

Any issue reported publicly in the issue queue of your module can be fixed at your convenience as long as it is not present in a stable release. The new release can be marked as “Security update,” as depicted on Figure 6–8, although you will need to contact the Security Team to get it published.

Summary

In this chapter you have learned the security processes to keep your Drupal site secure and how to leverage the infrastructure that the Drupal community has put in place to help site maintainers keep their code base secure. You've also learned that the APIs supplied by Drupal make it easy for module developers and themers to write secure code. Give it a try!