Review of the Drupal Configuration in terms of Security

In the first part of the series on Drupal security audits, we described how to review modules and libraries. However, modules and dependencies will be useless if any user will be able to see our custom routing where we display all the client information. Therefore, in this article we'll look at the configuration of our website. Correct configuration is one of the key elements affecting security.

Checking the Drupal configuration

For this part, our list will include checking the role permissions, access to the Drupal views and routings, among other things. We'll also verify the correctness of the text formats configuration and perform other checks to find the largest number of potential vectors of attack on our application.

Role permissions audit

By going to /admin/people/roles, we’ll see the list of all available roles.

In the list on the right (the OPERATIONS column), after clicking we can select the edit permissions option, which will redirect us to the page /admin/people/permissions/[machine_name_of_the_role] (example for the Anonymous role: /admin/people/permissions/anonymous). After going to the permissions edit, Drupal will list all the possible permissions that have been granted for the selected role.

To verify the permissions, we should first consider what task is assigned to the role. We need to ask ourselves whether role X should have permission for action Y, for example: should the content editor role be able to edit all views? If the answer is no, the permissions should be restricted.

Full knowledge of the project is required for a permissions audit. If we find a permission that we believe a given role shouldn't have, we should only inform in the audit report about the possibility of the role having optional permissions. We'll provide more information on how to create a good report in one of the next articles in the Drupal security audit series.

View permissions audit

After auditing the roles, it's time to take a look at the views. They're all listed under /admin/structure/views.

Our first task, in this case, will be to enter into the edit of each view that provides routing. We need to find the PAGE SETTINGS section, and more specifically – the Access option, which should only intentionally be set to "Unrestricted".

As is the case with the roles, when auditing the view permissions, we should ask ourselves: what restrictions should be put on the X view? If the view should be accessible to everyone, it's good practice to use a restriction which requires having permission to access the published content. If any of the views have no restrictions or we find them to be too moderate, we should inform about it in the report.

Audit of the routing.yml files in custom modules

When it comes to the routings created in custom modules, the audit looks similar. We should review every *.routing.yml file to ensure that every routing has the appropriate level of security. Here is an example of a new routing declaration

In this case, every user with the access content permission is permitted to access the /machine_name/transliterate page. It's also a good practice in this case to define a minimum access level for every access content routing.

Text formats audit

The path /admin/config/content/formats contains all the text formats available on the page. In this case, the audit will consist of checking, for example, whether it isn’t possible to insert JavaScript code using a given text format or whether it isn't possible to link an image that will be downloaded from another page. It's also important for the list of possible file extensions not to allow uploading files with unsafe extensions if it isn't necessary. Of course, we report the configuration errors – the risk level depends on the type of error.

Error logging audit

There is the Error messages to display configuration option on the /admin/config/development/logging page. It's used to set the error display level. This option should be set to None on the production page. If this option is set to a variant other than None in the production environment, we report it as a low-level threat.

Basic login audit

There are two ways for the login panel to inform if the user trying to log in provided incorrect data. It may give a brief answer such as "data is incorrect", or give one piece of information when the login is incorrect, and another when the password is incorrect. In the last case, we're dealing with a vector for a brute force attack. The attacker may first storm the logins and then the passwords – thus gaining access to the user accounts.

Another aspect worth checking out is the password policy. It's a controversial topic, since some propose to force a password change periodically, and others say that the password should contain at least one uppercase character, one lowercase character, one digit and one special character. Some people combine both these rules, and users end up creating passwords like July2021! which meet all the requirements. My personal recommendation in this case rules out the necessity to change the password from time to time. Determining the complexity of the password is recommended, but the most important thing is its length - the longer the password is, the more time it'll take to crack it. The password policy is an issue that depends on the type of project and must be analyzed individually. In the case of a weak password policy, you should report it as a threat with a level depending on how bad the policy is.

Forms audit

The forms should be protected against spam. They should be created using the Drupal API where possible. Check if the forms are protected against spam and if their validation doesn't allow entering incorrect or dangerous data. If you find an incorrectness in the form's configuration, you should be reported – the risk level depends on the situation. There'll be a different level of risk for a potential SQLi, and for the possibility of entering incorrect data – for example in the select list.

Additional recommendations

There are Drupal modules that increase the security of our application. One such module is Security Kit. Thanks to it you'll reduce the likelihood of using the website's security gaps. This module offers Anti-XSS, Anti-CSRF, Anti-ClickJacking, and other security measures. We recommend reading the linked post and considering the installation.

Security Review is a module that can help with a Drupal security audit. It uses automated security tests that help with performing the audit.

This module:

• checks the file permissions,
• performs a file formats audit,
• performs an audit of the options responsible for reporting errors,
• performs an options audit, in which we determine which file extensions can be uploaded (e.g. to be downloaded in a blog post),
• monitors database errors in order to detect a potential attack,
• monitors the login panel for the same purpose,
• checks the configuration of the trusted hosts file,
• checks the view permissions.

Security Review is recommended as it can speed up the process of auditing the page.

Drupal configuration checked - what's next?

In this part of the series on performing a Drupal security audit, we've learned the ways of checking the Drupal configuration. We are familiar with the configuration options that can open attack vectors and we know what the recommendations are for closing these vectors.

Acquiring the knowledge provided in this post has allowed you to better understand that a correct Drupal configuration is as important as keeping it up-to-date. A configuration audit is another of the activities that we perform during a security audit - our Drupal support team recommends a comprehensive configuration check during a security audit.

In the next part of this series of articles, we'll deal with the code and learn about the basic ways to audit it. We'll present the ways of analyzing modules and themes. We'll take a look at what's in the repository. Are there any passwords, keys in it? Or maybe the entire database dump?