Analysis of the Drupal Code Security

In the previous parts, we focused on Drupal configuration and the overview of modules and libraries. In the third part of the series on conducting a security audit, we'll focus on the overview of custom modules and themes. We'll perform an audit of the project repository, identify and analyze the elements worth paying attention to during the auditing process.

Overview of custom Drupal themes and modules

In custom Drupal themes and modules, attack vectors are most likely to appear. There's code there that isn't being widely used, unlike the code for contrib modules and themes. Therefore, it's not so well-tested in terms of security. In this article, I'll discuss a basic checklist used for auditing custom Drupal code. This list can be used as the basis for an audit of custom modules and themes.

Routing

We’ll start with the analysis of the parameters received from the user. Let's check out what is their type and how are they filtered. Drupal allows for using parameters in routings. These are dynamic values, incorrect processing of which may create attack vectors. If a query is created on the basis of a parameter and not filtered, this may cause a vector for SQL Injection attack, for example.

Next, we should look at the routing access configuration, specifically – the permissions that the user must have to get access. When declaring the routing, we need to define the requirements that the user must meet to gain access to the routing. We have to analyze the required permissions for every routing specified in our custom Drupal code and consider whether their level is appropriate. Specifying too low or incorrect level of required permissions will result in users having access to pages that they shouldn’t have access to. These can be both the pages listing the articles on your page and the pages listing all users along with all the data assigned to a given account. For this reason, the permissions audit is so important.

Forms

First, we'll analyze the correctness of the element types and check out if the correct type for a given field has been used. During the analysis of the types of fields used in the form, we may come across a field whose name and description suggest that it should be filled out with data of a specific type. However, the field's definition may allow the field to be filled out with other types of data. We should make sure that the definition of the type of elements corresponds with their purpose.

The next step will be to analyze the used methods of validating the field values in the form. Drupal allows for defining custom methods that validate the correctness of the entered data. We should test the correctness of the custom validation methods and make sure that only the valid data passes the validation.

The last thing will be to verify the presence and correct use of Form API provided by Drupal. We should analyze the way of using Form API, preferably using the documentation, and make sure that the forms are being created as directed.

The documentation specifies:

• the cases where the use of a given field type is correct,
• how to create the methods of validation,
• how to use hook_form_alter,
• how to create forms to be intuitive for the user.

SQL queries

Let's start with verifying the presence and correct use of the Database API provided by Drupal. It's equipped with methods providing security against attacks on the database. The correct use of API largely protects against attacks. We should particularly pay attention to whether input data filtering methods are used in the SQL queries. Drupal recommends using placeholders if there's a need to use input data, e.g., from a variable the value of which has been specified by the user in the form. Here's an example:

$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = ‘ . $foo[‘name’]);

In the code above, we can see that the value 'name' from the $foo array is being assigned to the query without filtering. In such cases, I recommend using placeholders.

$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = :name’, [‘:name’ => $foo[‘name’]]);

By creating queries in this way, we subject the variable $foo ['name'] to filtering, which will protect the query against SQL Injection attacks.

Filtering mechanisms

This means verifying the presence and correctness of the filtering data received from the user. We need to check that only TWIG is being used to render the variables in the templates, which by default filters the content of the variables and makes sure that they're safe. In the case of working with variables that are then used in translatable strings, we need to make sure that those variables are substituted for the appropriate placeholders. The plain text coming from the user should be filtered using the Html::escape() method if the user shouldn't be able to provide HTML tags in the text and the Xss::filterAdmin() function if they should be able to do so. If the user provides links, they should also be filtered.

Used for this purpose are the functions UrlHelper::stripDangerousProtocols() and UrlHelper::filterBadProtocol(). Filtering mechanisms are also applicable on the client's side. To clean up text in JavaScript, we should use the Drupal.checkPlain() function.

Sensitive data

We should check whether the code doesn't contain credentials or API keys. In some cases, we may come across the credentials left in the code of custom modules. Identifying them doesn't require much work.

Repository review

It's worth taking a look at the repository to search for sensitive information that may be stored in the files. The first step is to analyse the settings.php file and ensure that there are no credentials in it that would provide access to the database or other Drupal website components. Next, let's go over the environment variables' files and make sure there aren't any credentials in them. The credentials required by the environment shouldn't be part of the repository.

The next step is to check if there are no deeply hidden confidential files, for example – with SSL private keys or database copies or dumps. Sometimes the files that should never be in the repository get there by mistake. Some of them are, for example, database dumps or private keys. Identifying and removing them is recommended.

Analysis of the Drupal code – summary

In the third part of the series on performing a Drupal security audit, we've learned the ways of checking the code of custom modules and themes, we've audited the project's repository in order to make sure that no sensitive data was publicly available, and we've analyzed the elements that are worth paying attention to during the audit process.

Applying the tips I've posted in this article will make your application more secure. A code audit is a key element leading to better page security. It requires more time and knowledge than the update we covered in the first part and the correct configuration of Drupal we covered in the second part of the series, but the benefits of doing it are much more valuable than the time spent on it.

In the next part of this series of articles, we'll learn about external tools for automating the auditing process. It's the next step performed in a comprehensive security audit. Do you need help in performing such a task? Our Drupal support team has extensive experience in conducting audits.