Over the years, Zivtech has worked on many different types of existing Drupal websites and web applications. These projects have ranged from sites that were built with Drupal’s best practices to those built by developers with little to no Drupal experience. At Zivtech, we typically call a website that follows little to none of Drupal’s best practices a “lemon.” Our CTO, Jody Hamilton, did a great two part blog series called Lemon: Drupal Diseases and Cures if you would like to know more about what a Drupal lemon is.
If your site fits into the category of a lemon, it likely requires too much work to fix and should probably be rebuilt. In many cases though, our developers find that we can “rescue” the site to get it back into a secure and maintainable state after a site audit. We perform a site audit to identify the issues that can be fixed, and then provide an informative report about what problems have been found and how we can resolve them.
Our extensive experience with site audits has helped us identify common mistakes that Drupal sites are often guilty of. In this post we’ll outline the common mistakes and configuration issues that we find on most lemons. Some of these issues are even common on sites that have mostly followed Drupal’s best practices.
Outdated Drupal Security Advisories for Drupal Core and Drupal Contrib projects are the cause of the most common issue we encounter during our site audit process. In many cases, the sites we audit have not been maintained properly for an extended period of time. This results in Drupal Core and Drupal Contrib projects falling behind on varying levels of Drupal Security Advisories.
The worst case scenario is a Drupal site that has not been updated to at least Drupal Core 7.32. These sites are most likely already compromised by the Drupalgeddon Security Advisory. A much more in-depth security audit will typically be done in this case to ensure that the site is secured and cleaned up from the Drupalgeddon exploits.
Overall, we look to lock down any security holes from Drupal Security Advisories as a top priority for client sites, especially sites with user data. These are the first tasks that we perform after the audit when we begin to fix the identified issues.
When these settings are not configured properly, the site visitor’s browser must perform, in some cases, many more requests to render the page content, slowing down page load times. When configured properly, this setting will speed up a site’s page load times and overall performance.
The PHP Filter module has thankfully been removed from Drupal 8 core, but we see this module enabled on Drupal 7 sites more often than we would like. Not only is this a huge security hole, as it allows PHP code to be run directly on your Drupal site by malicious users, but it’s also difficult to disable without a thorough review of the content.
Without a thorough review of the content tables in the database, you could very well expose PHP code in plain text on the site that could end up an even worse security hole if not identified prior to disabling the module.
Many of our site audits include reviewing and fixing poorly written or poorly optimized custom module or theme code written by previous developers or development shops.
PHP developers who are just getting started with Drupal often make the mistake of using straight PHP instead of Drupal’s API. For instance, not applying the check_plain function to the t function on a Drupal input field is a common mistake that we find. Without the check_plain function, the field is vulnerable to a XSS, Cross Site Scripting attack.
This is obviously a major security concern. We want to notify the client immediately and start making the changes needed to lock down their custom code. Identifying and resolving these types of issues are of the highest priority during our site audit process.
Drupal’s Input Filters are overlooked by many who are inexperienced with Drupal, but they can be a huge security hole if not configured properly. On most problem sites, we find that either the Full HTML Input Format is configured for all users, or the Filtered HTML Input Filter has had its HTML filtering disabled.
Both of these configurations can potentially allow malicious users to embed code on your site that you probably don’t want your users accessing. To resolve this issue, we ensure that all default and custom Input Filters on the client site are configured securely. We also look through the database for potentially malicious code that has already been injected into nodes or comments.
During different stages of a site’s development, there may be changes made to use one module over another for similar functionality. This is a common but low risk issue that we find.
Allowing unused module and themes on the site can lead to security issues if no one manages Security Advisories in a timely manner. They also lead to much larger databases. Uninstalling modules and themes that are no longer in use is one of the final steps in our site audit as we start to look at ways to optimize the file system and performance of the site.
Another common but low risk mistake is the overuse of content types. We find many content types that exist that aren’t even being used.
Keep in mind that each field added to a content type adds about three database tables. Minimizing content types to only those that are necessary helps keep your database size down. It also helps content editor usability by removing confusing content types.
Once we identify all of the content types that are needed, we verify which ones can be removed and start cleaning them up. You might be surprised how much space in your database is wasted space.
User roles are one of the most overused systems we find during site audits. Overusing roles not only makes your site permission structure harder to manage, but it also can slow down your site considerably, especially when trying to manage permissions in roles.
Misconfigured role weights can also lead to major security holes. By default, Drupal provides some roles to get a site started, and in some cases additional roles must be created to provide the correct permission level for a given user. Sometimes roles are used for cases when something like Organic Groups would be a better choice. In other cases, it’s just impossible to manage the permissions page without having to edit each role individually to modify the permissions, which can be very tedious for site administrators.
To remedy this sort of issue, we typically discuss with the client how their users should be able to interact with the site through user stories. Then we determine how the existing user roles and permissions can be improved or simplified for their use cases.
Many of the sites that we audit have been online for several years. This usually means that there are at least a handful of outdated staff and admin users that should possibly be blocked, removed, or downgraded at the very least.
During an audit, we look to identify any weak links in the user roles, permissions, and user credentials to ensure that the site is as secure as possible on the user side. This may include adding a password policy, removing or blocking old users, and changing old admin or staff roles to less permissive ones.
In the end, we want to ensure that the users who can access the site through logging in are only those that the client wants to connect to their site. This makes for better security and user experience.
In addition to the overview that we provide, we also look at the server configuration, file permissions, and other aspects of the site’s hosting infrastructure.
There are a few common server and file permission issues we run into during audits. We typically find that either a server is configured improperly to allow improper access to the site’s files, or the web server itself is giving away information like its version number to anyone who wants to know. The version number could be the only information an attacker needs to perform a 0-Day exploit or other exploits that have not been resolved.
The sites that have these issues are also the ones that we find with many Drupal Core and Contrib Security Advisories, which increases the chance of serious security issues. Server configuration and permission issues are another high priority issue that we work with our clients to resolve as soon as we find them.
A site audit is often the first step in improving your website. Our audit process has made our team familiar with common issues like these and how to fix them. If your site is outdated or was built by inexperienced developers, engage a team of experts for an audit to ensure that your site isn’t vulnerable to attack and to improve overall performance and user experience.
Jason has been working with computers professionally since 1999, when he started as a Windows Systems Administrator. Since the dotcom bubble burst, Jason moved on from Windows IT and started working on websites. He got his first taste of Drupal in Drupal 5 supporting 3 Drupal websites for his employer.
View the discussion thread.
Tell us about your project