Drupal Security Modules and Best Practices for Your Website

The security of the solutions we provide is a very important factor for us. Due to this and the fact that Drupal is the safest CMS, in this article, we'll present the list of recommendations that'll take the security of your Drupal website to an even higher level.

Drupal security. Why is it good to stay up to date?

Your application is less susceptible to exploiting known vulnerabilities. That's it. But it means so much more.

As I've mentioned before – updating modules and libraries is one of the simpler methods of improving the security of our application. The Drupal community supported by the special Drupal Security Team constantly monitors the user reports on potential security bugs and offers to help the modules' authors solve them. The result of these actions are module updates that introduce security patches.

Configuration of the login panel

An incorrectly configured login panel may provide information about the existence in the database of a user using the login provided in the form. If the information that the panel returns in the case in which the attacker provided an incorrect login is different than when the login is correct, we're dealing with a brute force attack vector. This way, the attacker may obtain the logins first and then deal with brute-forcing the passwords.

Drupal modules increasing website security

Drupal has several modules that may improve security. Their configuration doesn't require extensive technical knowledge and doesn't take as much time as other methods of securing a website. We present below some tools of this type.

Drupal Password Policy

The Password Policy module allows for enforcing restrictions on the users' passwords by defining password policies. It can be defined by a set of requirements that must be met before a user password change is accepted. Every restriction has a parameter that specifies the minimum number of important conditions that must be fulfilled to meet the requirement.

Let's suppose we're limited to uppercase letters (with parameter 2), as well as limited to numbers (with parameter 4). This means that a user password must contain at least two uppercase letters and at least four numbers to be accepted.

The module also implements the "expiring password" function. The user is forced to change their password and is optionally blocked when their old password expires.

Drupal Password Policy allows administrators to force specific users or entire roles to change their password the next time they log in. The request to change the password, along with the appropriate form, appears as a popup instead of redirecting the user to the typical user/{user_id}/edit page.

Drupal Security Review

The Security Review module automates the testing of many easy-to-make mistakes that cause the website to be unsafe. This Drupal module is intuitive and very easy to use. The quickly-prepared report is legible and clearly indicates what needs to be improved. The module doesn't automatically introduce changes to your page. The results of the report should be analyzed, and – in selected cases – appropriate corrections should be made. Not all recommendations will be acceptable. It all depends on the unique factors of your website.

Drupal Security Kit

The Security Kit module provides a variety of security-enhancing options to help reduce the risk of various vulnerabilities in your application being exploited. The module reduces the likelihood of using many types of attacks, including:

• cross-site scripting,
• cross-site request forgery,
• clickjacking.

The full description of the functionalities can be found in the article linked above.

Source: Drupal.org

Drupal Paranoia

The Paranoia module identifies most places where the user can execute the PHP code using the Drupal interface and then blocks them. This reduces the potential threat resulting from the attacker gaining high-level authorization in Drupal.

What does the module do?

• Blocks the grant of the use of PHP for block visibility permission.
• Blocks the ability to create text formats that use the PHP filter.
• Blocks the ability to edit the user account with uid 1.
• Blocks granting the permissions that may reduce the website security.
• Blocks disabling this module. To disable it, you need to edit the database.

In order to take full advantage of this module, you need to identify all the entities, fields, and blocks that use the Drupal PHP filter and change them so that they work without it, and then remove the standard PHP filter available in admin/config/content/formats.

How to create secure code in Drupal?

Drupal uses the solutions that are assumed to be secure when used according to the standards. There are many rules you need to follow when creating a secure code. We present the most important of them below.

Use Twig

The Twig engine "auto-escapes" all variables by default. This means that all the strings rendered by the Twig templates (e.g., everything between {{ }}) are automatically cleared of the elements that may compromise the security of your application.

When rendering the attributes be sure to embed them between quotation marks " or apostrophes '. For example, class=”{{foo}}”, not class={{foo}}.

Use placeholders

Translation API also cleans up strings. Use it for the strings you want to translate and later, for example, render on the frontend side.

In Drupal, there are three types of placeholders in the Translation API:

@variable

We use it when we want to substitute a string or an object of the MarkupInterface class for a placeholder.

%variable

We use it when we want to embed a value between the tags.

:variable

We use it when the value we want to substitute is the URL we want to embed in the href attribute.

You can find more about placeholders at Drupal.org.

Learn the API and use it

Drupal provides many features for cleaning up strings. Among them are:

t(), Drupal::translation()->formatPlural()

Used along with the placeholders described above, it allows for creating secure strings ready to be translated.

Html::escape()

Used to clean up plain text.

Xss::filterAdmin()

Use it when you want to clean up the text entered by an admin who should be able to use most of the HTML tags and attributes.

UrlHelper::stripDangerousProtocols(), UrlHelper::filterBadProtocol()

Useful for URL checking, can be used together with SafeMarkup::format().

The strings that have passed through the functions t(), Html::escape(), Xss::filter() or Xss::filterAdmin() are automatically considered safe, as are the strings produced by the render array from the Renderer class.

Filter text also in JavaScript

Server-side text filtering is considered to be one of the best practices. However, there are cases where filtering will also take place on the client side to provide additional temporary filtering capability. It's useful, for example, when rendering the elements that are updated as the user types the text (that is, there are changes to the DOM tree being introduced). To filter text in Drupal by using JavaScript, you should use the Drupal.checkPlain() function. This feature cleans up the text by removing the harmful elements and protects against, for example, some clickjacking attack methods.

Use an abstraction layer when working with a database

We recommend never using pure values in the queries. You should use placeholders instead.

Example:

\Database::getConnection()->query('SELECT foo FROM {table} t WHERE t.name = ‘ . $_GET['user']);

Vs

\Database::getConnection()->query('SELECT foo FROM {table} t WHERE t.name = :name', [':name' => $_GET['user']]);

In the second case, instead of using the value from the user parameter directly, we provide it as the :name placeholder substitute. This way, before putting this value in the final query, Drupal will first clean it from the elements that could cause SQL Injection.

Security audit

The process of "hardening" a site should end with a comprehensive security audit that will catch even more potential threats on your page.

A security audit should include:

Modules and libraries review. This means checking the versions of the installed Drupal modules, reviewing the patches, PHP libraries, and JavaScript.

Configuration review. As part of this activity, we carry out authorization audits for the roles, views, routing.yml files in custom modules, text formats, error logging and forms.

Repository review. We check the custom modules and themes, including routing, custom forms, SQL queries, filtering mechanisms and file permissions.

Repository contents identification. We audit the contents of the settings.php and .env files. We also conduct an audit of deeply hidden elements. It's based on checking the repository for, for example, SSL private keys or database copies or dumps.

You can find the full description of many of the elements presented in the above list in the linked articles.

Drupal security modules - summary

Depending on the level of advancement and knowledge of Drupal, you can introduce appropriate corrections to the application to make it more secure. The examples presented in this article will definitely reduce the number of attack vectors and the likelihood of using them. We recommend analyzing the available options and possibly introducing the changes or new elements that'll reduce the risk of an attack on your application. If you need help with such activities, our Drupal support team can conduct an audit of your website security.