CheapWindowsHosting.com | Today we will learn about how to improved drupal security. As we know 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.
Even though Drupal 7 is still supported, upgrading to Drupal 8 is recommended for the many security enhancements as well as usability enhancements.
Because of core coding changes in Drupal 8, existing modules have to be re-written to support Drupal 8. This has unfortunately caused a delay in adoption of Drupal 8 as many sites rely on various contributed modules which in some cases have no Drupal 8 counterpart or only experimental versions still testing in Drupal 8.
Drupal 8 finally includes the ability to update modules from the web interface. Drupal 7 security has been perceived as poor in large part because of many sites not updating Drupal core or any associated modules. With Drupal 7, 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 8, and is somewhat similar to the web-based updates that WordPress users have been enjoying.
Other Drupal 8 security benefits include:
Keeping Drupal up-to-date is the fundamentally most important security consideration.
Drupal security consists of three areas to maintain security updates:
Drupal Core update announcements are available from http://drupal.org/security.
As of Drupal 8, every window in the Administration interface notifies of a pending Drupal Core update.
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.
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 8′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).
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:
Red Hat or CentOS, edit the following file:
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.
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:
$ sudochown -R jsmith:www-data /var/www/drupal
To temporarily switch permissions to allow updates, change the owner to the apache user:
$ sudochown -R www-data:www-data /var/www/drupal
Next perform updates, then set permissions back:
$ sudochown -R jsmith:www-data /var/www/drupal
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.
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.
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.
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.
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 8 as soon as possible is strongly encouraged by this author for the many security benefits outlined. The problematic maintenance and upgrading of Drupal 7 is much improved in Drupal 8 which will help users to keep sites and code more up-to-date against today’s seemingly growing threat of attack against web applications. For a deeper look into Drupal and other web application security, check out the web application penetration testing course offered by the InfoSec Institute.