Drupal web development is on the rise today - there are hundreds of thousands of sites written in Drupal. The community of Drupal developers keeps growing. So Drupal is regularly checked, scanned, analyzed for security vulnerability. Drupal has been developed (and keeps being developed) in such a way as to prevent critical security vulnerabilities, including the Top 10 security risks determined by the Open Web Application Security Project (OWASP). Drupal proved to be a reliable software product used for creating websites for serious companies and organizations, including the US White House.
The Drupal core is well protected by default, but we can unintendedly open its vulnerabilities through insecure configuration. For example, such simple things allowing untrusted users to use any HTML tag in comments may enable cross-site scripting attacks. So do not rely on the Drupal core security measures, but also follow additional security rules that can protect your site from attacks and other threats.
Drupal security releases
The Drupal core security releases are numbered according to the standard version numbering scheme, so no indicator is added which would specify that this or that version has some security amendments. For example, core version 7.34 is a security release that fixes some security vulnerabilities, while the previous version 7.33 is a regular maintenance release which fixes some bugs and makes some improvements to Api. So one of the ways to make your site more secure is regular Drupal core update. See more about the core releases here: https://www.drupal.org/node/1173280
Deleting/blocking a user
Drupal sites may allow users to delete another user, or even themselves. Sometimes this can lead to unforeseen situations where anonymous users can view or edit pages on a site that they should not be able see at all. This can happen if removed users left their nodes or comments. This can be avoided in two ways: 1. by blocking users instead of deleting them. 2. by deleting users with "Cancel account" command, using the option "delete the account and make all the user’s content belong to anonymous User".
Using HTTPS
The HTTPS protocol encrypts http requests and responses. It ensures that even if someone were able to compromise the network between your computer and the server, they would not be able to listen in or tamper with the communications. HTTPS is typically used in situations where the user will have to send secret or personal information, and the interception of such information may lead to problems. Usually it includes: credit cards passwords and logins identification information (social security number, address, postal code) confidential information.
Especially in situations where you as administrator need to send the main user’s password or ftp password to your server, you should use https wherever possible, to reduce the risk of damage to your website. Managing https traffic requires more resources than managing http requests (both for the server and the browser), so you can use a combination of these two protocols on your site as needed. Read more about HTTPS settings for Drupal website here: https://www.drupal.org/https-information.
Prevent the execution of unreliable PHP code
You must understand what consequences there may be of allowing users to run php. This happens when the user enters a php code in the form, submits the form, and then PHP is run on the server. This user will be able to edit and even delete any files that the server will allow (that are available). In most cases these are Drupal site files in the "files" folder.
PHP can also be used to change the database or steal information from there. In such cases, the tables can be removed, the content altered, the personal data of users modified or extracted. It is especially dangerous if the site is commercial, because the financial information of the user is exposed. There are many ways to take control of your site if running php script.
It is also important to make it impossible for outsiders to read the settings.php file (even if it belongs to another Drupal installation), because the login and password to access the database are written there.
There are two main ways of executing php code which poses risk to the site. The first way is through the existing site code that evaluates incoming text as php, for example, modules that support the php text format. The second way is when a dangerous php code is executed because a user uploads the file with the code to the file system.
Modules that allow the execution of php code should give access to it to the trusted roles only, or even only to a user with uid 1. If you find a module that allows dangerous execution of php code without corresponding remarks or control, you should avoid using this module.
File upload functionality provided by the Drupal core helps protect your site against the php code execution, limiting the allowed file format. By default, files with .php extension are not supported. On the other hand, if the php code is included in the file with another extension and the web server is configured to execute this file as php, then the trespasser has a chance to attack the server.
You can deal with this by properly configuring the .htaccess file for Apache servers. Of course, this file should be protected from editing by the web server. You can also protect yourself by properly granting access:
- User user/1 usually has access to install modules that executes php code.
- The “Administer permissions” access should only be given to trusted roles, because users who have such access can give themselves any other access.
- The “Administer users” access lets you edit the main user (user/1), change his password and log in from his account. Here, too, you should avoid giving untrusted users such opportunities.
A few words should be added about text formats for forms. In no case should you give anonymous and other users without trusted roles the access to Full HTML format, as the site’s visitors will be able not only to insert pictures into text, but add dangerous JavaScript-code there. It is better to give such users access to the Filtered HTML format. Of course, you should not allow untrusted users change access to text formats from the admin/people/permissions page.
User №1
The account that is created during Drupal installation and has an uid equal to 1 (user/1 or SuperAdmin) is special. First of all, it can bypass all access callbacks - that is, by default, it has full access to the site. It’s very important to protect this account because otherwise it may pose serious risks. To protect the main account, you should follow the rules.
First of all, avoid such user names as “admin”, “administrator”, or others that are easy to guess.
The main user can be disabled. As any other access can be granted to other users with the appropriate role, the everyday use of SuperAdmin is not mandatory. And if you occasionally need to use this account, you can enable/disable it at any time using drush:
drush user-block 1
drush user-unblock 1
or through MySQL:
UPDATE users SET status = 0 WHERE uid = 1
UPDATE users SET status = 1 WHERE uid = 1
It is necessary to set a complex password for the main user. To do this, you can use the user_password php function which generates a random alphanumerical password. To make it through drush, you must enter this command in the terminal: drush php-eval 'print user_password ();'
Hide information from users
It is not so important, because attackers can find other ways to get the information about your site. But it’s a good practice to give potential attackers as little information as possible. This applies, above all, to error messages. In Drupal you can show or hide these messages. For development, it is useful to see them, so you can see what needs to be fixed, but on a live website you need to hide these messages in order to prevent the disclosure of information such as the full path to system files or the structure of the tables in the database.
Such files as README.txt, CHANGELOG.txt may contain information about versions. They can be deleted, but it is better to move them beyond the site or rename, as they may contain useful information.
How to check the website for security, and some tips for site protection
There are several useful tests that allow you to check the security level of your website:
If the test shows no threats, it does not guarantee the good level of website security, it just shows that the site poses no immediate threat to visitors.
Often the goal is attackers is the menu_router table in the database. An interesting case is described on the https://www.zoubi.me/ site when the trespassers modified the database to write malicious data there. Therefore, it is necessary to check whether you have something like that.
Infected sites may have additional users or even admin roles. Check the "user_roles" and "users" tables for any suspicious records. Hackers often use such names as drupaldev, megauser, system, admin122. If you are more suspicious, check the “sessions” table for suspicious activity.
It happens that in the /modules/ or /sites/ directory, hackers place php files with malicious code, and database records can be found that lead to these files. One such case is described in the blog at https://www.reddit.com.
There were cases when hackers deleted the lines containing protective measures from the .htaccess file, so it's always best to have a backup version of this file and check it from time to time for changes that may have been made.
To test your Drupal site for security, you can use site_audit. This is not a module, so it should not be installed as a module. This is a set of commands for drush, so it is installed respectively. All instructions are in the README.txt file. New commands analyze various site settings like caching, unused content types. They analyze which development modules are enabled (they should be disabled on a live site), which are disabled, but not uninstalled yet, etc., and offer recommendations for improving the security and productivity of your Drupal site.
An interesting example of hacking the database is presented in the blog. Drupal core 7.31 and lower versions had one vulnerability. A function that sends queries to the database from the form (including login forms) did not verify the array keys. So, instead of a key, any SQL command could be executed. Everything was done very simply: 1) we edit login form through inspect element 2) instead of the name value that will be the array key, we enter enter the SQL-injection and try to login to the site 3) even if we fail to log in, the command successfully runs to harm the database.
This bug was fixed with just one code line in the patch 7.32:
There is one interesting feature for drush called drupalgeddon. It allows you to make another check of your Drupal website security.
Sometimes beginners have an idea, and they ask on drupal.org: how to hide from visitors the fact that the site is written in Drupal? Drupal.org replies: you can not do this, do not try. First of all, automatic attacks do not investigate the server before attacking. It is dangerous to change the core files for the sake of masking, because you can make a mistake and it will become more difficult to update the core through a real security update.
Also drupal.org provides many useful tips on writing security code. For example, do not use variables from $form_state['input'] array, data comes there directly from the form before any processing, writing secure database queries and much more.
Security team
Drupal community has its own security team which analyzes the core and contributed modules, views users’ security reports and writes documentation about the security of Drupal websites, as well as offers security code writing tips and more. To learn how to write a Drupal website security issue, follow this link.
Overview of Drupal security modules
A lot of modules have been developed that make it possible to increase the security of your site. Here is a brief overview of some of them.
Drupal Security Review is a module that checks the site for settings that can create vulnerabilities to attacks. It is convenient and easy to use.
Paranoia is module which, when installed, immediately hides itself, as well as the permission to enable users to execute php code through interface, eliminates the possibility of creating input formats, which use php filter, disables the option to edit the main user, and other features that could fall into the hands of untrustworthy users. This module also disables the option to remove yourself (this can be done only through the database).
Hacked! is a module which checks if changes have been made to the core or contributed modules or themes. It can be run through drush. If the diff module is enabled, you can even see the changed code lines.
Security kit is a module which adds various options for security enhancement. This reduces the risk of damage to your Drupal site.
Encrypt is a module that allows you to encrypt and decrypt data, for example, to save various confidential information in the database, including the support of four coding methods. There are modules that add their encryption functionality, for example, Encrypt form api allows you to encrypt form fields.
Captcha is a text that is added to the form to check if the user is a human or a bot (probably everyone has experienced this - it somehow reminds the Turing test). There may be captchas resembling mathematical operations such as adding, the result of which must be entered, but most often it is a picture with almost unreadable text that only a human can read. There are many modules that complement this one by adding their types of captchas.
AES Encryption provides additional ways to encrypt/decrypt data using the Advanced Encryption Standard. On the basis of this module, others have been written, such as Encrypted files, which allows you to encrypt files that are uploaded to the server and decrypt them if the user downloads them from the site, so the server stores only encrypted file versions.
Conclusion
Drupal itself will not protect your website from all dangers, it only enables you to organize your site security at your discretion. For this purpose, security updates and web developers’ recommendations are written, contributed modules are created, but it is also necessary to configure your Drupal site so as to reduce the risk. Drupal just gives you the ball to play - and it’s up to you to play it well!