In part one of this post, I went over how Drupal Security Advisories, SSL/TLS certificates, and thorough user account security help lay the foundation for keeping your Drupal site secure. In part two, we’ll take a look at user roles and permissions, input filters and text formats, and third party libraries.
User Roles and Permissions
To keep your site secure, always make sure that your user roles and permissions are configured properly. Depending on the modules installed and third party integrations, there could be additional permissions and/or roles to configure to ensure the site is still secure after installing a particular module. It’s important to read the full module README and/or module documentation to verify that all configuration options and permissions have been set up securely. In many cases, modules with very important security related permissions will either set them to a sane default configuration, or put up a notice on the modules page within the admin UI. Some will do both. Some will do neither, so that’s why you need to be aware.
For each module you enable, there can be optional or required permissions that need to be configured. This is one of the easiest things to overlook as a Drupal beginner, so keep an eye on which modules you’re enabling, and if you have permissions set for all your roles before launching the site.
User 1, the superadmin account, has full access to a Drupal site without needing any additional roles or permissions assigned, so testing with that user is not the best. Create some test users within each role and test how the site works logged in and logged out to be certain that your roles and permissions are configured properly. You should only grant your most trusted admins access to the User 1 account. It’s also a great idea to rename the User 1 username from admin to something custom to avoid easily guessing or enumerating the superadmin username.
Obscurity is not security, but in some cases it does help to further secure the User 1 and other admin accounts on the site when using other security best practices. Disabling the User 1 user completely through MySQL is a more heavy-handed approach to locking down the superadmin user.
There are also contrib modules that help facilitate additional obscurity on top of your user security, such as Rename Admin Paths and Username Enumeration Prevention. These modules can help keep potential hackers, script kiddies, and bots guessing instead of providing them with easy to use information in their hacking attempts.
Input Filters and Text Formats
Input filters and text formats are a huge part of ensuring a Drupal site doesn’t get hacked. The wrong settings on an input filter or the text format for a text field, such as a comment field, can be an easy way in for potential hackers.
Content editors should be able to add the content they need without compromising security. Certain input filters should be enabled in the text formats for every format to ensure that HTML can’t be malformed and that markup can’t be added to exploit the site.
The most common of these exploits is a Cross Site Scripting attack, which ultimately tricks the database into allowing code submissions to the database in a malicious attack. These types of attacks can end up with a hacker taking over your whole server, or just your database, but this can be prevented with the proper text formats and WYSIWYG settings. Let’s take a look at some of the most important settings to configure to ensure your fields are sanitizing all their data properly before being submitted to the database.
The HTML filter is probably the most important input filter provided by a text format. It allows for specific tags, and even specific attributes of a given tag, in the actual HTML. Without the HTML filter, your site is open season for hackers, script kiddies, and bots to muscle their way in through possible exploits.
It’s important to ensure that embedded objects, such as <script> and <iframe> tags, are not allowed, or only allowed by trusted users. They can easily be used to run malicious code on a site from external locations. There’s also a newer filter available that disallows usage of <img> tag sources that are not hosted on the site by replacing them with a placeholder image. Be aware that when you create a new custom text format, no input filters are chosen by default. It is highly recommended to use the “Limit allowed HTML tags and correct faulty HTML” HTML filter as a minimum.
There are four text formats available in Drupal core out of the box; Basic HTML, Restricted HTML, Full HTML, and Plain Text. In general, you probably want to give most users Basic HTML, but you might want to give your content editors more control over the markup they can add. Adding an editor role to the Restricted HTML format with some customized settings may be a good idea for those users.
You want to give the least permissive text formats to untrusted users, so Plain Text is a great choice for comments on blog posts to avoid spam links and malicious markup that isn’t filtered properly. Text formats can also be associated with a WYSIWYG, so be sure to enable or disable that for roles you trust or don’t trust as much.
Note: Keep in mind that new text formats and WYSIWYG settings can create new permissions on the site, so be sure to review all roles and permissions again after getting these configured.
Third Party Libraries
One of Drupal’s strengths is how easy it is to integrate with third party JavaScript libraries through contributed themes and modules. The problem is that these third party libraries are not covered by the Drupal Security Team, so they don’t get their own security advisories like Drupal core and Drupal contrib projects do.
There have been a few cases when very popular libraries like CKEditor have received a Public Service Announcement on the Drupal Security Advisories page. PSAs like these are not very common unless there is a major security advisory for a third party library, or possibly a major incoming security issue for Drupal core that developers should be ready for. This is something that’s often overlooked, even by seasoned Drupal developers.
The lack of a true security advisory built into Drupal for these third party libraries means that it is up to you and/or your team to ensure that any libraries you have installed are still secure. This typically means that you need to sign up for security alerts for that project, if they have them, or keep an eye on the project releases that are security releases. Again, there are times that you might get a warning from the Drupal Security Team in a PSA about a library’s upcoming security release, but don’t count on this as a reliable way to prevent an attack; it’s not the Drupal Security Team’s job to monitor every third party library out there. Luckily, many third party libraries are hosted on GitHub and have an easy to follow releases page, although some do not and require a bit more due diligence to follow the latest security releases. Wouldn’t it be great if every open source project had such an amazing security team like Drupal’s?
Conclusion
A comprehensive Drupal security plan usually requires team effort. There are plenty of options out there to ensure that every Drupal site can stay secure, so don’t leave your site out in the cold for hackers to compromise it, or, even worse, steal user information and post it publicly for other hackers to use. This has become a common trend with sites that are hacked, which creates a bad situation for both the company that was hacked as well as for the users who had their data stolen.
If you don’t have the time or resources to keep your site secure, seek the help of a team of experts. Keep calm and stay secure out there, fellow Drupalers!