There’s no foolproof way to get an unhackable Drupal site; there could always be an exploit that we don’t know about yet. But there are quite a few ways you can help reduce the risk of getting hacked. Let’s dive into some of the most common ways Drupal sites get hacked, and how to secure your site against these points of entry.
Drupal Security Advisories
One of the most common ways to get hacked is to fall behind on known Drupal Security Advisories. Keeping up to date on the latest advisories is ultimately your first line of defense.
There are security advisories for both Drupal core and contributed projects with varying levels of security risk for the exploits found. You can sign up for the security email list to make things easier to keep track of. You can do this by logging into your Drupal.org account and editing your user profile. From there you can subscribe to the security newsletter on the newsletters tab. This list will email you soon after Drupal Security Advisories are released to the public, which helps quickly notify you or your team of possible exploits that need to be fixed.
You can use the Update Status module in Drupal core to see which sites are affected by these advisories. Then add an email address to send Security Alerts to daily or weekly. The Update Status alerts have also notified us in a few cases when the email list was backed up and took longer than it normally would.
Typically, Drupal core security advisories come out on the third Wednesday of the month unless it’s a highly critical update that needs to be patched sooner. Contrib project security advisories can come out on any given Wednesday.
Drupal 8 has a new release schedule that schedules upcoming minor releases. It’s important to note that with a new Drupal 8 minor version release, the previous minor version becomes unsupported and no longer gets security advisories or updates. It will be important for development teams to plan for these updates moving forward with Drupal 8, as these updates are not typical to the release schedules of Drupal 6 or Drupal 7 core.
The Drupal core release schedule for both Drupal 7.x and 8.x can be found on the Drupal core release cycle page on Drupal.org. The overview page outlines the upcoming Drupal 8 core releases and major project milestones. Get familiar with them if you don’t want to be blindsided by some updates you weren’t planning on doing that quarter.
Specialized Drupal hosting companies, such as Pantheon and Acquia, have started applying security updates upstream to your codebase, which can be merged with the click of a button in most cases, or even automatically with some additional configuration. This allows Drupal core security updates to be applied with less effort to sites that are hosted on their platforms. Drupal contrib is still up to you to support though. Other companies like Drop Guard and myDropWizard provide various service plans to keep your whole site up to date and not locked into a specific hosting platform.
Whether you’re looking to do your Drupal security in-house, host on a specialized hosting service, or pay for a support service provider to handle it for you, Drupal Security Updates are by far the most important aspect of your Drupal site’s security. Instead of derailing this whole post about why Drupal Security Advisories are so important, Google “Drupalgeddon” if you are unfamiliar with the term, and you’ll quickly see why they’re at the top of my list.
Use SSL/TLS for All the Things!
Unencrypted login forms are an easy way for hackers to gain access to a Drupal site. All websites, especially those that have any sort of authentication process, should be using SSL/TLS encryption by default by now.
SSL/TLS encrypts the communications between a client browser and the server to ensure that all data being transferred back and forth is encrypted from end to end. This stops hackers and malicious users from eavesdropping on data that you’re sending or receiving from the web server.
This encryption is extremely important for any sites that require authentication, such as Drupal or WordPress sites, as they both have administrative users that can potentially be hacked if the login form is not secured. It’s imperative that sites that handle financial information and other personal identification information always use SSL/TLS, otherwise that data should be considered compromised. You’ll know when your browser is in a secure SSL session; you’ll see various levels of validation, starting with a green lock saying “Secure” next to it and https:// at the start of the URL in your browser address bar.
Sites that are not secured by SSL/TLS are vulnerable to malicious users being able to “listen in” on the unencrypted communications between the client browser and the web server through various methods. This information could be login credentials, personal identification information, or something like payment information, which should always be encrypted when sending electronically.
Encrypting these communications with SSL/TLS stops this from happening unless you are involved in a “man-in-the-middle” attack, which involves spoofing the SSL certificate itself and posing as a real, secure site. It’s good practice to verify that the certificate in the browser is actually owned by the site by clicking the green lock and viewing the valid certificate information.
Any site can get an SSL cert now through the Let’s Encrypt service, so cost or availability is no longer an excuse for running non-SSL websites. Pantheon’s hosting service even provides SSL certificates powered by Let’s Encrypt for all domains on your account as part of their hosting plans.
Extended Validation (EV) certificates provide additional information about the owner of the certificate directly in the address bar, such as the company name and/or the country the cert was issued for. Generally, you’ll see these Extended Validation (EV) certificates used by financial institutions or larger corporations, but they can be used by any website that fills out the information needed for the Extended Validation certificate. At the time of this writing, Let’s Encrypt does not support Extended Validation certificates or wildcard certificates, so there are still some cases that it is not fully applicable, but it’s a great, free service for non-EV and non-wildcard certs.
Drupal User Account Security
We now know that our communications between the browser and the server are encrypted through SSL/TLS, but do we know how secure our Drupal users’ passwords are? To keep your site secure, ensure that all users, especially your content editors and admins, are not your weakest link. There are multiple levels of user security we need to be aware of when setting up our Drupal website. We’ll take a look at these levels and make sure we have all our users connecting as securely as possible.
Let’s start by taking a look at our most common weakest link, the user password. While there is a nice password strength suggestion tool in Drupal core, there’s nothing in core to force users to use secure passwords out of the box.
At Zivtech, we use the Password Policy contrib module on most Drupal site builds to ensure that all users have password requirements that make them more difficult to crack. We typically require several elements to the password, such as numbers, capitalization, and punctuation, to add to the complexity of each user’s password. This is important to ensure that privileged users and those with the ability to add content to the site do not have their accounts compromised by a weak password.
Drupal does have some mechanisms built in that will throttle failed login attempts, but these reset over time and the process can be repeated unless additional steps are taken to block the IP. Ultimately, weak passwords can be an easy point of entry for skilled hackers.
Proper administrator and content editor training is also important to ensure that these users don’t unintentionally negate other steps that were taken to secure the site. This means that site administrators and content editors should be informed that sharing login credentials over insecure communications like email should never happen. Credentials shared across email and other unencrypted communications should be considered compromised as soon as you hit the send button. There are some great password managers out there (we use LastPass) that store encrypted credentials and even allow sharing of credentials securely between team members. Always use one of these tools instead.
PSA: If you are still sending any passwords or login credentials over email, please stop before you cause a major security breach in your organization or a client’s!
Check back next week for part two! We’ll go over security for user roles and permissions, input filters and text formats, and third party libraries.