Drupal Secure Configuration

Purpose

This document is intended for third party or outside developers who are developing Drupal sites in whole or part which will be housed on the SAS Computing central Drupal server. Due to the shared nature of the server environment and the commitment of SAS Computing to the highest level of support and uptime it is necessary to impose certain restrictions on all sites (and code) that will be deployed on the production environment.

Modules

Each module installed on the Drupal development server must undergo a thorough security audit before being deployed. Many modules have already been approved through this process. Please reviews this list, carefully select the additional modules you wish to employ, and request security reviews as early as possible. Security reviews insure that modules deployed on our production environment are stable and free of security problems. This protects your site as well as other Drupal sites.

On average it takes about 4 hours to review each 1000 lines of code in a Drupal module. The ISUS staff have 8 hours a week to review modules, so two small modules can be reviewed in a week. Be sure to plan for this time delay when requesting new reviews of modules. Please be aware that this time estimate is very rough and some modules may take more or less time to review depending on their functionality and complexity.

Modules that are marked as unstable, buggy, or not fit for production environments in their own documentation will not be installed on the production environment in order to protect not only your own, but others' Drupal sites.

It is a good idea to check the outstanding issues with a module you're requesting. If there are lots of active bugs reported, especially if many of them are critical, this may be a sign that the module isn't stable.

Modules that are designated 'alpha', 'beta', or other pre-release, by the developer typically indicate that the code is either incomplete, buggy, or otherwise unfit for prime time. According to official Drupal documentation "These releases are not yet stable enough for production use." (https://www.drupal.org/node/467020). Additionally the Drupal security team has stated:

This module [..] in alpha and not considered suitable for any production environment. Drupal Security Team only deals with vulnerability reports that are related to major releases or release candidates. Instead we encourage reporters to contact the module maintainers and fix any issue in the public issue queue. Please refer to https://www.drupal.org/node/475848 for more detail.

Mori Sugimoto
Drupal Security Team

Because modules in these early stages are not managed by the Drupal security team and are inherently subject to change we do not, as a matter of course, install modules designated with pre-release versions.

Modules that are labeled as 'dev' are unsuitable for production environment as they are specifically designated for testing and debugging. In order to provide the highest level of integrity for all centrally hosted Drupal sites we will not install any 'dev' modules.

Be sure to select only modules that have versions for the currently installed version of Drupal. Also be sure to note any prerequisites or supporting modules that must be installed in order to install the module you are requesting. Some modules require several dependencies and these may inflate your audit request significantly.

PHP

All PHP code should be restricted to modules. Templates should be utilized for display purposes only. Every effort should be taken to minimize the use of PHP code in the templates. PHP should never appear in CSS or directly within node content.

It is important that developers follow the Drupal secure coding guidelines posted by the Drupal security team. Following these guidelines will insure that code avoid common security pitfalls.

The PHP input type has been removed from the production environment. No site or module should require the utilization of PHP code through the Drupal web interface. All PHP code should be produced by developers and packaged in appropriate module or template containers.

All PHP based privileges (for things such as visibility, post processing, etc.) should be disabled. No group should be allowed to use PHP for any purpose. This not only aids in security, but also ensures that users cannot inadvertantly damage their site.

File Uploads

File uploads are restricted to images and office documents. If other file types are needed (such as video or executables) for site completion, please inform SAS Computing staff at the earliest possible opportunity.

User Settings

The UID 1, or administrative account, that is created when Drupal is installed should be disabled. This account has all privileges and these permissions can't be limited or revoked. Leaving the account active could allow an attacker to take conrol of it. Creating a new group with specific administrative permissions and adding users to that group is preferable.

User accounts should be restricted to PennKey holders whenever possible. In the case that non-PennKey holders will be requesting accounts administrator approval should be required. At the very least anonymous account requestors must reply to an e-mail confirmation. Anonymous account creation should not lead to a situation where the user could create unapproved content. Thus, if anonymous users can provision accounts, the authenticated user group must not have any privileges to create, edit, or delete any content or administer the site, without administrator approval or oversight of some kind. This restriction will help prevent spam or damage to the site from anonymous users.

Comment Settings

Anonymous, unapproved comments with full HTML should not be allowed. This presents a link spam opportunity for attackers and opens the door to inclusion of malicious JavaScript and cross site scripting vulnerabilities in comments.

Node Creation

Only authorized users should be able to create nodes. Content creation should be limited to authenticated parties that have been vetted by Penn staff.

Drupal Authentication Security

The Institutional Research and Application Development (IRAD) group within SAS has created a custom CoSign module for PennWebLogin that utilizes the University central authentication system for web applications. Wherever possible this form of user authentication should be used. However, recognizing the fact that many Drupal sites will be deployed to service communities beyond PennKey holders, there are facilities for utilizing Drupal "native" login, that is Drupal accounts independent of PennKey. The latest version of the PennWebLogin module is designed to allow for the creation of non-PennKey accounts within Drupal.

One of the primary concerns for mixed authentication, that is using PennKey and Drupal native authentication, is potential conflict in name space. Without proper precaution it would be possible for a user to create a Drupal account with the same name as a PennKey account. This would result in confusion when users logged in and accounts might become indistinguishable. For this reason the new PennWebLogin module alters the Drupal account creation process to ensure that Drupal accounts may not exist within the PennKey namespace. The module accomplishes this task by prepending a "d-" to the beginning of new usernames. Because dashes are illegal characters in valid PennKeys the module ensures there will be no namespace collision.

Security Concerns with Drupal Authentication

Native Drupal authentication does create some security concerns that must be addressed. Drupal handles user authentication in many ways that create security vulnerabilities. Careful configuration and use of additional modules can help to mitigate these vulnerabilities. All sites that use Drupal native authentication should be mindful of the potential dangers and impose the following configurations to ensure maximum resilience and security of the Drupal authentication scheme:

Password Security
The Drupal Password Strength module has been installed for use on all Drupal sites. This module should be enabled and require the use of strong passwords. By requiring strong passwords, your Drupal site will be more resistant to brute force, or password guessing, attacks.

Login Security

The Drupal Login Security module is available and should be installed and utilized on all sites. The Login Security module should function invisibly for any site using PennWebLogin for authentication. The Login Security module will alert site administrators to failed authentication attempts and impose a delay in response for each successive failed login attempt. After a certain threshold is reached the module will block logins for accounts and alert administrators of the problem. This module will prevent password guessing attacks against Drupal sites and monitor failed logins to alert administrators of potential problems prior to user complaints.

SSL

If you use Drupal native authentication be mindful of the fact that user login information is sent unencrypted over the network in Drupal's default configuration. This could lead to credentials being exposed to malicious users observing traffic. With the proliferation of free wireless hotspots and other unmanaged connections this is an increasingly likely scenario. Consider using SSL only connections to your Drupal site in order to mitigate this threat. In order to accomplish this your site must have a valid sas.upenn.edu domain name or you must purchase an SSL certificate for your site. Talk to the system administrators about making your site available exclusively over an encrypted connection.

Passwords in Email

By default Drupal will transmit passwords for accounts over e-mail. This usually happens when a new user account is created. The default e-mail template sent to users includes the account username, password and a link to a one time login page. Because the user can utilize the one time login link there is no real reason to send the password via e-mail. The danger in sending passwords via e-mail is that the e-mail is usually transmitted over unencrypted channels and once delivered is prone to loss due to a compromised e-mail account, lost mobile device, etc. In order to mitigate this threat it is important to remove the password placeholder token ("!password") found in each e-mail template under Administer -> User management -> User settings.

COMPUTING