Guest Post: Drupal Security Notes

Wed, 08/22/2012 - 10:24 -- John Maher

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.

Story Type: 

Comments

Submitted by Guest (not verified) on

I am also looking for an web development to grow my business online but i am quite confused while selecting the CMS, i mean to say that there are various CMS in the market so how we can choose which one is better?

Submitted by John Locke on

Hi,

It depends on your needs, budget, and longer term strategy.

As a die-hard open source advocate, I would say first of all pick one of the many fine Open Source alternatives -- it greatly reduces your risk of being able to get your data out should there be a problem, and by definition you can always find developers to help. You can hire an employee and let them learn it if nothing else.

If your budget is tight and all you need is a blog and a brochure site, it's hard to beat Word Press. Especially if your marketing/growth plan is not entirely based on needing a custom web application to manage your business.

If you have more sophisticated needs, we think Drupal is where it's at, as long as you have competent Drupal talent available. There are lots of horror stories about Drupal projects gone awry, built by people who did not know how to do it in a maintainable, upgradeable way, or by people incapable of properly planning and delivering a good result. But with good talent available, you can do pretty much anything in Drupal that can be done on the web.

We think Drupal's a great fit for a client extranet (a portal site for you to interact with your customers and vendors on a secure channel), a directory, e-commerce (when you need more than you can get from a simpler hosted platform like Shopify/Etsy/Amazon etc), event management, CRM, and a lot more. Especially when you want to consolidate several of these functions into a single system. It can certainly do everything Word Press can do, but for very simple sites, it will cost you more, largely because Drupal developers are in short supply compared to demand, and so competent ones charge quite a bit higher rates.

But basically it comes down to your developers. We see really nothing that can't be done in Drupal, but we totally recognize that Word Press has a well-deserved place in the market place. Between the two of them, we don't see a need to compare other systems -- at the low end, Word Press does everything you need, and at the high end, Drupal does. But if you have a great developer you trust to deliver an excellent result, go with their recommendation -- the skills and ability of the developer is far more important to the end result than the platform.

And remember that the launch of a web site is really the beginning of the project, not the end -- so when shopping around for somebody to build a site for you, be sure to discuss what happens after the site launches.

Thanks for wonderful security primer! I didn't know about these security modules before reading the article. I'm a themer / site builder and want to start testing my themes for XSS vulnerabilities. What tools should I use for XSS testing, especially on a windows development machine?

Add new comment

  1. I wanted to touch base and thank you for your team’s quality work on the FHCRC eagle-i connection project.  The system is live and in production – pushing our Drupal content automatically to Harvard’s system.

    We’re very grateful for all the efforts your crew put into this project! Freelock is on my speed dial for future projects!

    Ann Marie Clark
    Fred Hutchinson Cancer Research Center

Need More Freelock

       

About Freelock

We are located in Pioneer Square, in downtown Seattle. 83 Columbia Street #401 Seattle, WA 98104  USA [P] 206.577.0540 Contact Us/Directions | Site Map Get Updates ©1995-2014 Freelock Computing