Improving upon Drupal's Built-In Site-Hardening Measures

By Michael Ross

This article was published as a cover story in the print magazine Drupal Watchdog, Volume 6 Issue 2, Fall 2016, on pages 46-51, by Linux New Media. The magazine was distributed at Drupalcon Dublin, 2016-09-26.

Among the hundreds of open-source content management systems (CMSs) available for building websites, Drupal is not only one of the most popular, but it has rightly earned a reputation as one of the most secure. That is not to say that the software is flawless (no code base of any significant size could make that claim) or that security bugs have never been detected in the past or will be in the future. Rather, it is to say that, relative to its size and exposure to hacking attempts, Drupal has an excellent track record for securing data input, storage, and output — that is to say, protection of form submissions, information in the database, and authorized access to page content.

To a large extent this is a result of the efforts of countless members of the community who review and strengthen the code — especially the Drupal Security Team, a group of dozens of dedicated programmers who quickly respond to any and all known security concerns. Part of their mission is to receive and evaluate reports of security flaws detected in the Drupal core code, as well as the additional modules and themes contributed to the Drupal ecosystem. These dedicated individuals also assist core and module maintainers in fixing these problems. Once the security issues have been fully researched, resolved, and released, only then does the team announce them publicly, in the form of security advisories. More details as to how the community polices the project as a whole, can be found in a white paper, the "Drupal Security Report", authored by Benjamin James Jeavons and Greg Knaddison.

Nonetheless, there are countless methods for further strengthening the Drupal website that you may be building or maintaining. We will examine some of the contrib modules that can lock down a website even more than what is provided by Drupal out-of-the-box.

Security Kit

Because the Security Kit module (SecKit) implements a number of essential site-hardening improvements, it is arguably the first security module that you should consider for any public-facing site. It thwarts cross-site scripting (XSS) using several methods specific to web browsers. It also addresses cross-site request forgery (CSRF) attempts, clickjacking, and man-in-the-middle and eavesdropping attacks. As of this writing, it has versions available for Drupal 6, 7, and 8 (alpha).

Figure 1. Security Kit - cross-site scripting options

Figure 2. Security Kit - other options

Secure Pages

If your website has an SSL certificate, that is a big step in securing the data passing back and forth between your website and your visitor, because it allows for the strong encryption of any information transmitted between your web server and the visitor's browser. But the secure protocol (evidenced by a URL beginning with "https://") is not necessarily invoked on the web pages where you want it to be, unless the visitor has installed in her browser an extension such as HTTPS Everywhere (unlikely among the general populace) or manually types in the protocol name (possibly even more unlikely). So how can you force users — for their own good, of course! — to go to the secure version of your site's pages, or at least those where it is critically important?

The Secure Pages module, though only in beta, allows you to specify pages on your site, using simple pattern matching, so the system will automatically redirect visitors to the SSL versions of those pages. Needless to say, depending upon which contrib modules you are using to add e-commerce functionality to your site, if any, then you will need to specify different paths. But as an example, using Ubercart on a Drupal 7 site, you'll definitely want to secure http://www.example.com/cart/checkout, where customers enter their credit card information. By default, the configuration provides a sensible starting point.

Figure 3. Secure Pages patterns

If you are maintaining a legacy Drupal 6 site (lucky you!), then be sure to check out the Secure Pages Hijack Prevention module, which is designed to make "mixed mode" SSL more secure.

Username Enumeration Prevention

The phrase "username enumeration" may sound like the nightmare scenario in which a user repeatedly asks you to change their username to something new derived from the daily horoscope. But it actually refers to something more painful (well, perhaps): Anyone attacking your website can use various methods for learning the usernames of valid accounts, which increases your site's vulnerability. One of the most popular methods is to try each entry in a list of potential usernames, typically starting with common first and last names. Any susceptible site will helpfully inform the attacker — or, more likely, his webbot — that the username is invalid, i.e., try the next one on the list!

Drupal 7 and 8 fortunately have built-in brute force countermeasures, but if you want to use an extra prophylactic, consider the Username Enumeration Prevention module, which foils this attack by never informing the attacker of the (in)validity of a given username. Instead, the usual error message is replaced with the same message as for a valid username, and he is then redirected back to the login form. If the username does not exist in the system, then no password reset email is sent, but the attacker will not know this.

This attack is especially effective against Drupal 6 sites, and yet oddly enough this module is not available for that version, but instead only 7 and 8 (currently beta).

Security Review

Before you and your client go live with a shiny new website, it would be wise to let the Security Review module run through its checklist of common vulnerabilities, including: safe file system permissions (protecting against arbitrary code execution); text formats disallowing dangerous tags (protecting against XSS); no PHP or JavaScript in content (nodes and comments and fields in Drupal 7); safe error reporting (avoiding information disclosure); secure private files; and only safe upload extensions. Developers may be baffled by one of the advertised features, "password included in user emails", since Drupal fully encrypts passwords and there is no password token available for use in the account settings e-mails. But presumably that in some sense is part of the module functionality.

Figure 4. Security Review results

Shredder

Can you think of a reason why you would ever want to destroy all of the data in a client's Drupal installation, and yet keep the site's functionality completely intact? An unpaid invoice? (Just kidding.) One actual use case is if the data is confidential, and yet the site needs to be opened up to outsiders for one of many possible reasons, such as usability compliance certification or the testing of third-party components by their vendors. If you need such a data destroyer, then the Shredder module is certainly the force you should call upon. Once you begin the destruction process, you will naturally be presented with plenty of warnings, and then the digital shredding begins. Just make sure you have full backups or that you have declared "Release the Kraken!" on a clone of the site and not the original. It is currently only available for Drupal 7, so your Drupal 8 sites are still safe.

Copyright © 2016 Michael J. Ross. All rights reserved.