Guest Post: Drupal Security Notes

Drupal is one of the most popular free and open source web application frameworks. Drupal is almost infinitely extensible through not only various theme possibilities but also the vast library of modules or add-ons. However, this great extensibility is also a point of weakness should insecure or vulnerable code be used in either themes or community contributed modules that can result in compromise. The following guide on best practices for Drupal covers main areas of attention in regards to security for any Drupal web administrator.

1. Upgrade to Drupal 7

Even though Drupal 6 is still supported, upgrading to Drupal 7 is recommended for the many security enhancements as well as usability enhancements.

Because of core coding changes in Drupal 7, existing modules have to be re-written to support Drupal 7. This has unfortunately caused a delay in adoption of Drupal 7 as many sites rely on various contributed modules which in some cases have no Drupal 7 counterpart or only experimental versions still testing in Drupal 7.

Drupal 7 finally includes the ability to update modules from the web interface. Drupal 6 security has been perceived as poor in large part because of many sites not updating Drupal core or any associated modules. With Drupal 6, applying updates for general maintenance was somewhat problematic and inconvenient. This is perhaps what led to many sites putting off updates leading to many Drupal installations being compromised. Updating is improved in Drupal 7, and is somewhat similar to the web-based updates that Wordpress users have been enjoying.

Other Drupal 7 security benefits include:

Stronger security for stored user passwords

Passwords in Drupal 7 are hashed with phpass, combining multiple rounds and salted hashes. Drupal 6 and prior stored user passwords in MD5 in the database which is now considered weak and easily crackable.

Update notifications

Drupal 7 incorporates automated email notifications of any pending module or core security updates. This is also available in Drupal 6 via a module, but is now built in as functionality in Drupal 7.

Login Rate-Limiting

Drupal 7 now incorporates brute force login protection. Defaults are rate limiting for five failed attempts in a six hour window as well as rate limiting 50 failed attempts from one IP address per hour. This is configurable in modules/user/user.module.

2. Keep Drupal up-to-date

Keeping Drupal up-to-date is the fundamentally most important security consideration.

Drupal security consists of three areas to maintain security updates:

- Drupal Core updates

- Contributed Module security updates

- Theme security updates

Drupal Core update announcements are available from http://drupal.org/security.

As of Drupal 7, every window in the Administration interface notifies of a pending Drupal Core update.

Modules

Drupal module update announcements are available from http://drupal.org/security/contrib. Drupal 7 has built-in email notification for any outstanding module security updates as well to notify admins of pending updates. Resist the temptation to develop or write custom email forms or other elements for Drupal, but rather look for existing well-established modules that are written to serve various purposes. Existing modules have been tested for the most part in a wide install base and have had more eyeballs on the code to check for security flaws.

Completely remove any disabled modules from the server so as not to have any older vulnerable code live and present in web directories.

Check your sources

In choosing a Drupal theme, consider building upon or using a tested well used theme that has continued updates from the developer. Often users will pick a theme that is 'pretty' or meets other cosmetic requirements. However it is critical to inspect if the theme is currently being maintained for security updates. Do not install themes found randomly on the internet; only choose themes from Drupal's Download & Extend which have been recently maintained. Even then, closely inspect the source to be vetted before launching the code live in a Drupal installation.

Drupal XSS exploits through themes are not uncommon. For example the following theme is susceptible to XSS as one illustration: http://drupal.org/node/1608780

If creating a custom theme, thoroughly test the theme in an installation with various web application scanners, either open source or commercial, that test for XSS or SQLi prior to deployment.

drush

drush is the ultimate command line utility to manage Drupal. With drush, it is possible to do such tasks as clearing all Drupal caches, upgrade Drupal core and modules, apply database upgrades (similar to running update.php), enable/disable modules, and much more.

If not already using drush, this is a valuable tool to be on top of and easily patch any outstanding Drupal security updates. More information is at the following URL http://drupal.org/project/drush.

3. Enable SSH for Update Manager

The built-in Update Manager for updating through the web interface or installing modules in Drupal 7 has the ability to use SSH to connect to the host. This is of course the preferred way to transfer files instead of FTP. If SSH does not show up as an option in Drupal 7’s Update Manager, install the following PHP library:

Debian / Ubuntu:

$ sudo apt-get install libssh2-php

Red Hat / CentOS:

Red Hat and CentOS do not include ssh libraries for PHP. The required package php-pecl-ssh2 can however be installed from the EPEL repository (http://fedoraproject.org/wiki/EPEL).

4. HTTPS and Drupal

Drupal by default operates only over HTTP, including sending any login credentials in plain text. One solution is to have the entire site operate over HTTPS. But while perhaps having an entire site over HTTPS is not ideal as of date, steps can be taken to at least have credentials and other form submissions in Drupal to occur over HTTPS.

Drupal 7 by default uses the secure flag for HTTPS cookies to prevent session hijacking. The module Secure Login (http://drupal.org/project/securelogin) is a required module to help further take advantage of this feature. The Secure Login module allows not only logins but also form submissions in Drupal to occur over HTTPS and have a unique HTTPS session cookie that cannot be hijacked.

Along with the secure cookie flag, the httponly cookie flag can be set in php.ini on the server for another layer of security.

In Debian or Ubuntu, edit the following file:

/etc/php5/apache2/php.ini

Red Hat or CentOS, edit the following file:

/etc/php.ini

Use the following values to enforce the httponly flag for PHP session cookies:

session.cookie_httponly = 1

session.use_only_cookies = 1

Without these above changes, one could potentially intercept and steal the authenticated cookie to then gain authenticated access to the Drupal installation.

5. Web server permissions

Permissions of the directories and files in Drupal are critical for security. Files or directories should never be 777, nor are 777 permissions required for Drupal to operate. Directories should be 750 or 755 and files should be 644 or 640.

The Drupal directory and files should be owned by a regular user, and the group of the apache user. This can cause problems for automated updates. Temporarily changing permissions to have the apache user own the Drupal directory so to install updates may be required. Once updates are complete, change the Drupal directory back to be owned by a regular user.

This example command changes the owner to jsmith (example username) and group of the Apache user on Debian and Ubuntu for all files in the Drupal installation:

$ sudo chown -R jsmith:www-data /var/www/drupal

To temporarily switch permissions to allow updates, change the owner to the apache user:

$ sudo chown -R www-data:www-data /var/www/drupal

Next perform updates, then set permissions back:

$ sudo chown -R jsmith:www-data /var/www/drupal

6. Recommended Modules

In the security area, two recommended modules should be part of a Drupal installation.

The Security Review module (http://drupal.org/project/security_review) inspects various aspects of a Drupal installation including file system permissions, user auditing, database and other errors, as well as things such as input formats allowed. This module is also useful in that the interactive results detail how to fix or remedy various issues that apply to the Drupal installation.

Secure Login (http://drupal.org/project/securelogin) as mentioned above is a critical plugin to keep the security of authenticated sessions and form submissions free from session hijacking.

If still on Drupal 6, making use of a phpass module addon (http://drupal.org/project/phpass) will strengthen password hashes for users that are stored in the database.

7. Backups

Regular backups are a part of any system administration and that includes running and administering a Drupal web application. Two backups are required for Drupal: regular full database dumps and also regular snapshot backups of the entire Drupal directory. Should compromise occur, having the ability to roll back to a previous snapshot or compare files to a previous snapshot is invaluable. Creating either automated cron jobs to make backups or using a module such as Backup and Migrate (http://drupal.org/project/backup_migrate) is critical and should be part of the security administration for a Drupal installation.

8. Scanning and Auditing

Regular scanning of the Drupal site with web application scanners or vulnerability scanners is required today to be on top of security. At least monthly scanning at a minimum is a good interval if not more frequently. Many open source as well as commercial web application scanners are able to test sites for XSS and SQL injection which is very relevant to web applications such as Drupal.

9. Operating System Updates and Logs

Drupal security extends to operating system security, which is the host running the web server Apache as well as PHP. If Drupal is installed in a self-managed VPS or other similar installation, staying on top of OS security updates and patches are critical to ensure that the entire host is secure and free from compromise. Subscribe to various Linux distribution security update mailing lists or Twitter feeds to keep on top of any pending updates or security issues for the operating system that is hosting the Drupal installation.

Reviewing Apache or other operating system server logs daily is part of general security no matter what application or software is in use. Make use of logwatch or other automated log alert software to be on top of any trending patterns in logs from would-be attackers.

Conclusions

Drupal security is achievable by keeping on top of security updates for Drupal core and contributed modules as well as taking advantage of SSH and HTTPS options that are available. Most default Drupal installs provided by scripts in hosting companies do not have many of the above mentioned security notes installed or available, which leaves most Drupal users unknowingly connecting and managing their site via insecure protocols. Upgrading to Drupal 7 as soon as possible is strongly encouraged by this author for the many security benefits outlined. The problematic maintenance and upgrading of Drupal 6 is much improved in Drupal 7 which will help users to keep sites and code more up-to-date against today’s seemingly growing threat of attack against web applications.