Skip to main content

Articles tagged with "security"

Allow editors to use HTML attributes by default

26th Oct 2022

Drupal provides an excellent sanitisation system to filter the HTML content that editors might create. Think of it like a series of traffic cops that filter different vehicles into different lanes. Some content is allowed through to its destination, some has to be transformed along the way, and some is simply blocked from displaying. Administrators can use the 'Limit allowed HTML tags and correct faulty HTML' option to configure which HTML elements and attributes they can use. This helps protect a site against nefarious HTML - whether it might be malicious or just ugly. Under Drupal 9, editors can't use...

Read more

Apply Drupal 9 compatibility patches with Composer

12th Jan 2021

Update! Since this article was written, a new 'lenient' composer endpoint has been created on Drupal.org to support using modules with Drupal 9 that haven't been marked as compatible with it yet. See the documentation, which boils down to adding a new common entry under 'repositories' in your composer.json, above the usual https://packages.drupal.org/8 one. The rest of this article is still useful for understanding how patching fits into composer's workflow.

The vast majority of community-contributed Drupal 8 modules now have releases that are compatible with Drupal 9, but what can you do if you need to use a module that...

Read more

Customise scaffold files the right way

16th Jun 2020

There are some key files like robots.txt and .htaccess which are often tweaked for Drupal websites. These can be considered part of the 'scaffolding' of a site - they control the way the site works, rather than its content or design. Any new release of Drupal core that includes changes to them specifically mentions that they need updating, as those changes may have to be merged with any customisations made on your site. For example, there was a security release that added rules to .htaccess, which were essential for any site to incorporate and the template settings file, default.settings.php...

Read more

Notifying our clients about security updates for Drupal Core

Nathan Page
10th May 2019

Drupal receives security updates several times a year, and we always apply them as soon as possible. Since Drupal security issues can make the headlines, it's important that site owners know that their site is secure and up to date - it provides for peace of mind and for pride in an excellent site.

We decided this year to ensure that clients know about security updates to Drupal Core on their site. Via a quick email, we plan to let site owners know not only that an update has happened, but what was affected and how it worked. Keeping site owners...

Read more

Let's say NO to unsanitised inputs

Nathan Page
7th Mar 2019

Last night saw the popular EU Cookie Compliance module fall from grace, as the Drupal community discovered that numerous inputs in the admin form were not being sanitised.

To me, this shows some serious failings in how our community is handling security awareness. Let's do some fixing :)

1) We need to make this OBVIOUS, with clear examples

One of the most important things when trying to get people to write secure code is making them aware of the issues. We need Drupalers of all levels of experience to know and understand the risks posed by unsanitised input, where...

Read more

Security risks as Drupal matures

Nathan Page
12th Dec 2018

After reading this from Ars Technica, which describes how a developer offered to 'help' the maintainer of an NPM module - and then slowly introduced malicious code to it - I can't help but wonder if the Drupal community is vulnerable to the exact same issue. Let's discuss!

###Please, don't touch my package
NPM modules have been hacked at before, and it's not pretty when it happens. Because of the way we use packages, it's a lot easier for nasty code to get sucked in to a LOT of applications before anyone notices. Attacks on the code 'supply chain', therefore...

Read more

Beware File::getFileUri()!

9th Nov 2018

I'll keep this short and sweet, but we thought this would be a useful tip to share with the world as a potential security issue with the combined use of File::getFileUri() and FileSystem::realpath().

Consider the following code excerpt :

$file = File::load($some_file_uri);

if ($file) {
  $uri = $file->getFileUri();
  $file_realpath = \Drupal::service('file_system')->realpath($uri);
}

Seems pretty harmless right? Load up the file from $some_file_uri , If we have a valid file then get the URI and then grab the real path.

Wrong (potentially, depending on what you do with $file_realpath).

If $file is a valid file, but for whatever reason the file is...

Read more

SA-CORE-2018-004

26th Apr 2018

As with every other Drupal agency on the planet, it was another fun evening of frantic patching of client sites last night due to the release of the highly critical SA-CORE-2018-004 security update for Drupal, released on 25/04/2018.

Being so closely related to SA-CORE-2018-002 and knowing proven exploits for that were already affecting thousands of un-patched Drupal sites, time was of the essence for this one as a new exploit was sure to be released in a matter of hours.

Our crack team of developers who stayed late especially had all of our clients' production and testing sites patched within a...

Read more

Patching Drupal without server access

3rd Apr 2018

If you don't have access to the file system on the server for a Drupal site, when a security issue like Drupalgeddon2 comes along, you are entitled to panic! Many sites are run by a combination of teams, so sometimes you really don't have control over the server... but that might even mean there is another way to apply fixes. If you've been tasked with updating such a site (I was!), it's worth checking if the server has been misconfigured in such a way to actually allow you to patch Drupal, via Drupal!

A heavy caveat first: we would never...

Read more

Fixing Drupal, really quickly

3rd Apr 2018

Drupalgeddon2 happened! We got all but two of our projects updated within an hour, with those remaining trickier two fully patched another hour later. The key was planning the right process using the right tools. We actually use these tools for regular deployments every day, but speed was essential for this security update. Here's what we did, since some of you may be interested.

  1. Our on-call developers split up the various sites/environments/projects that would need updating amongst themselves, using a simple online shared spreadsheet.

  2. Ahead of time, we prepared pull requests for sites that simply use Drush make...

Read more