shutterstock_731465218

Drupal is the fourth-most used Content Management System (CMS) on the internet today, falling beyond only WordPress, Shopify, and Joomla. And it makes sense. It’s a developer’s dream when it comes to building a heavy-traffic site with a lot of complex content. Many love the flexibility and power of Drupal’s open-source format, and with a large community of users, there’s always someone to help developers make the most of their site build.

But when you’re in the middle of a new Drupal installation, it’s important to remember that Drupal sites are often vulnerable to attack. As you create your new site, now is the time to start with a solid, secure foundation, and to keep up with updates as you go to prevent devastating security issues.

For example? It only took hackers three days to start exploiting a security flaw, leading to hundreds of attacks back in 2018. Now, the frequency of attacks is on the rise. It’s more important than ever to avoid these pitfalls during your installation.

1. Forgotten Security Updates

One of the most common things that happen as organizations begin their website build is to not keep security updated as they go. This isn’t an issue that’s unique to Drupal. In fact, 95 percent of all websites on the internet today are backed by outdated security software that presents major security risks.

But there is good news when it comes to Drupal’s security updates. Drupal makes it easy for organizations to stay caught up with the latest security:

Security updates for Drupal are always released on Wednesdays, after 12 PM, Eastern time.

Security update releases for Drupal-contributed projects happen every Wednesday, and typically, the third Wednesday of the month marks the release of security updates for Drupal core. To make things easy, contributed project security releases generally do not come out on the same day as any core security release unless the core fix impacts the contributed project software.

You can get all security advisories for Drupal through their website:

What’s more? You can opt-in to receive emails announcing all new security advisories. To subscribe, log into Drupal and visit your user profile page. Click “Edit” then click on “My Newsletters” and ensure that the “Security Announcements” box has been checked, then click “Save.” You may also want to install the “Update Manager” module to view all current “Available Updates” reports to see what security updates have yet to be applied on your site.

Taking a few minutes each week—even while you build out your site—to ensure that all security updates have been applied is a critical step in warding off security breaches. You can keep yourself out of unwanted trouble. And since the average cost of a cyber attack is $2.6 million, it makes wise financial sense to stay up-to-date!

Additionally, attention should be paid to patches, which must also be updated and reapplied after module updates to avoid misconfigurations.

2. Insufficient Text Filtering and Other XSS Misconfigurations

Security is about more than just regular updates, though. As you build your new Drupal site, keep in mind that you can write in security vulnerabilities without meaning to. One of the most common potential vulnerabilities is a cross-site scripting (XSS) attack.

The Open Web Application Security Project, or OWASP for short, explains XSS attacks as “A type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user.”

These kinds of flaws are all too common, and can happen anywhere your web app requires input as you build your site, sending altered outputs to your users. When an XSS attack happens, it generates a malicious attack without validating it.

Most security issues in Drupal surround XSS vulnerabilities. How can you tell if an input is vulnerable to an XSS attack? If you see a <script> tag for content that other users will view your site, bad actors can use this information to access administrator privileges, then do anything that your administrators and site builders can do.

XSS errors can be hard to pinpoint and remove from your web app. To find them, you’ll want to perform a security review of your code, looking for any place where input from an HTTP request could alter the HTML output.

Drupal is stacked with security defaults, but as you install Drupal, it’s easy to create misconfigurations that leave your site open to attack. Text Formats is an example of where this can happen. Text Formats should be one of the most important lines of defense when it comes to keeping you safe from XSS attacks, and also help you format and display your inputs.

To get an automated review of your site’s Text Formats, you can use Drupal’s Security Review module.

3. Problems with File Extensions

Drupal gives users free rein to add File fields to any and every content type; each one with a different group of file extensions. The issue here is that this creates unsafe vulnerabilities that are easy to exploit. Bad actors can use these file extensions to gain full control of your entire site.

It’s similar to the issues that come up with XSS vulnerabilities—and the process is chillingly simple.

Attackers merely need to add a second extension to a malicious file before uploading it on Drupal through an open field.

That’s all it takes to have the malicious file executed. When uploaded to the Drupal site, the file is incorrectly classified as a text file, then Drupal executes the malicious code as it reads the text.

This is true of any unsafe extension: HTM, HTML, JS, or SVG; any file extension where a web browser would execute Javascript.

Drupal developers share that without the right updates and close watch, vulnerabilities exist because Drupal doesn’t sanitize some file names. Malicious files can slip past protections and wreak havoc. Normally, files with double extensions would be detected right away, but these vulnerabilities make it easy for problematic extensions to make their way through. In addition to staying updated with security patches, users should also take a close look at their extensions to ensure hackers have not already taken advantage of this vulnerability.

4. Multiple Module Copies Within the Same Layer

Drupal was designed to allow multiple copies of the same module in the same layer or directory space. One might live in /core/modules, another might exist in /modules and yet another may be found in sites/all/modules.

But the issue here? If you have copies of the same module set up in the same layer, Drupal accepts the first one, then ignores any subsequent module copy.

Drupal itself describes this situation as “an unstable state,” because developers don’t know which module copy is the one Drupal is actually using; they have to inspect the system table to figure out which one is being used.

What this means is that if you have two or more copies of the same module in a layer, it’s essentially a code error.

As you build your site, you can use ExtensionDiscovery: : scanDirectory() to index extension names and keep track of their uniqueness. This will set off an exception anytime it discovers extensions with the same name. The exception message will help you determine which modules are already registered, whether any modules can be removed, and which one to remove.

5. The Presence of PHP in the Database

PHP is an acronym for Hypertext Preprocessor. It’s an open-source, all-purpose language used in coding, most frequently for web development. It can also be embedded into HTML.

For years now, PHP has had a bad reputation—and rightfully so. PHP is used as commonly as other scripting languages like Python and Javascript. The problem? Its advancements are far behind other options and are least popular among developers. Why is this? At this point, recruiting a PHP programmer who’s capable and available is a tall order. Also:

You need more developers to support your operations, compared to other scripting languages
Using a combination of languages (for example, PHP and Java) muddies the waters. It lessens the efficiency and quality of your final product.
PHP has been left by the wayside in years past, most often only used as a server-side programming language
Most enterprise applications run on other languages and other technologies that have surpassed the abilities of PHP.

Even with all of these factors in mind, PHP is still used by 78 percent of all websites that use known server-side languages.

Thanks to its prevalence, some may be tempted to implement PHP code, but this can give bad actors the power to exploit lesser vulnerabilities, even creating a Remote Code Execution (RCE) vulnerability. Also, when PHP code is saved in the Drupal database, it’s a tough road. PHP code is infamous for being hard to maintain but all too easy to break.

PHP code is only supported by Drupal 7, which is coming to end-of-life at the end of November 2022 and will no longer be supported—which also means no more security releases. If your site still has PHP language or a PHP module, it needs to be disabled and removed as soon as possible, especially if your organization is planning to migrate to Drupal 8 or Drupal 9. Alternatively, you can also use the Paranoia module, which disables the features in modules that allow entering PHP.

Get Top-Notch Drupal Support

The intricacies of a secure, new Drupal installation are vast—and there’s no room to leave things to chance. To learn more about Drupal’s architecture and its benefits, take a look at what we have to say about the CMS platform here.

Get the support you need for a successful, fortified installation. The Engine Room team values a polished, professional, top-performing site as much as we value a site that’s designed to keep you defended from potential attacks—and we’ll deliver both. To learn more about how we can help, consult with our experts today.