Comment sécuriser votre site Web sous Drupal contre les cyberattaques ?

En introduction, voici quelques chiffres pour bien comprendre qu’un site Web est constamment menacé.

• En 2021, un site internet était en moyenne attaqué 172 fois par jour... soit une augmentation de 210 % par rapport à 2020. ⁽¹⁾
• Toujours en 2021, 54 % des entreprises françaises ont subi des cyberattaques. ⁽¹⁾

Au vu de ces chiffres, il est important de comprendre que la sécurité de votre site internet se doit d’être un processus constant, transverse et en amélioration continue. Qu’entendons-nous par ces 3 termes ?

• Constant, car la supervision des différents aspects organisationnels, techniques et structurels doit être maintenue en continu, et les audits faits régulièrement.
• Transverse, car le processus concerne tous les aspects d’une organisation, interne et externe, de l’humain aux infrastructures en passant par la technique.
• En amélioration continue, car il faut rester en veille et remettre en question les pratiques pour les améliorer.

Dans cet article, nous allons nous concentrer sur les bonnes pratiques, spécifiques au CMS Drupal, à mettre en œuvre pour assurer la sécurité de votre site Web.

Les mises à jour du CMS Drupal

L’un des points majeurs de la sécurité pour tout projet informatique est de maintenir ses dépendances techniques à jour. Dans le cas de Drupal, on parle évidemment du Core et des modules contribués, mais aussi des dépendances de ces derniers : Symfony, CKEditor, etc.

Quel est le cycle d’évolution de Drupal ?

Depuis sa version 8, Drupal a adopté un cycle de mise à jour prédictible et calqué sur celui de Symfony.

Source : Drupal.org

Les versions correctives ou de sécurité (10.0.4, 10.1.2, etc.) sortent tous les mois et concernent non seulement le Core, mais aussi les modules, les thèmes et les distributions contribués.

Les mises à jour de sécurité sont publiées les 3e mercredis de chaque mois. En cas de faille majeure, la mise à jour peut sortir en dehors de cette fenêtre.

Les versions mineures (10.1, 10.2, etc.) sortent environ tous les 6 mois et incorporent les nouvelles fonctionnalités. Elles continuent de bénéficier de correctifs de sécurité pendant 1 an à compter de leurs sorties.

Les versions majeures (9, 10, 11, etc.), quant à elles, sortent environ tous les 2 ou 2,5 ans, en même temps que la dernière mise à jour mineure précédente, et incluent les mêmes modifications sur les éléments stables. Ces changements ne concernent que :

• L’augmentation des exigences PHP (8.1 pour Drupal 10) et système,
• La mise à jour des dépendances vers les nouvelles versions majeures,
• La suppression du code déprécié lors du précédent cycle de développement majeur.

Retrouvez ici la documentation officielle sur le sujet.

Quel est le statut des différentes versions majeures de Drupal ?

Il n’y a que 2 versions majeures de Drupal actuellement supporté : Drupal 7 et 10.

La version 7 a vu sa vie allongée à plusieurs reprises, notamment à la suite du COVID, jusqu’au 25 janvier 2025. Passé cette date, les sites internet développés avec Drupal 7 ne seront plus couverts par les mises à jour de sécurité. La migration sur Drupal 10 ou 11 nécessitera une refonte complète de votre site Web. Je vous conseille donc de lancer votre projet de refonte au plus vite, si ce n’est pas déjà fait. Notez que pour votre projet de refonte de site, Adimeo peut vous accompagner… n'hésitez pas à nous contacter !

Si votre site internet est encore sur les versions de Drupal 8 ou 9, vous devez faire la mise à jour vers la version 10 au plus vite. Cette opération ne nécessite pas une refonte complète. Elle se réalise dans un temps restreint, entre 2 jours et 10 jours selon la complexité de votre projet et la présence éventuelle de modules obsolètes.

Comment rester informé des mises à jour ?

Pour effectuer les mises à jour dans les temps, encore faut-il avoir eu l’information. Il existe 4 principaux moyens pour se tenir informé et agir en conséquence. Vous pouvez les retrouver dans la documentation officielle.

Pour vous aider, je les ai listés pour vous :

> Directement via votre site Web

Il est possible de paramétrer votre site internet pour qu’il vous envoie des notifications mail, chaque jour ou chaque semaine, listant les mises à jour en attente. C’est le module du Core « Update Manager » qui permet d’ajouter cette fonctionnalité.

Attention, pour réussir ce paramétrage, il est nécessaire que le CRON soit fonctionnel et que votre site soit capable d’envoyer des mails. Dans le cas où vous gérez plusieurs sites, ce n’est peut-être pas la meilleure méthode, puisque les mails vont être nombreux.

> Via la newsletter de sécurité de Drupal

Cette newsletter est envoyée à chaque release de mises à jour de sécurité et liste toutes les notices de vulnérabilités concernées. Comme le dit la documentation officielle : « Pour vous enregistrer, se connecter à Drupal.org, aller sur la page de votre profil d’utilisateur et s’inscrire à la liste de diffusion sur l’onglet Edit > My newsletters. ». C’est la méthode que je trouve la plus pratique.

> Via le compte X (ancien Twitter) @drupalsecurity (https://twitter.com/drupalsecurity)

Si vous êtes plus présent sur X, ce compte publie un poste pour chaque notice de vulnérabilité.

>Via les flux RSS officiels

Il existe 3 flux séparés :

• « Core security updates » : mises à jour de sécurité du cœur ;
• « Contributed project updates » : mises à jour des projets contribués ;
• « Public service announcements » : annonces de sécurité publique.

Pourquoi utiliser l’outil « Composer » ?

« Composer » est un outil essentiel pour maintenir un projet PHP comme Drupal, car il simplifie la gestion des dépendances.

Cela signifie qu'il aide à gérer les bibliothèques et les packages externes dont votre projet a besoin pour fonctionner. Sont inclus le Core de Drupal et tous les modules, thèmes ou distributions contribués que vous utilisez.

En utilisant « Composer », vous pouvez facilement installer, mettre à jour et gérer ces dépendances, ce qui facilite la gestion du code et assure une meilleure stabilité et sécurité de votre projet Drupal.

Vous trouverez ici la documentation officielle quant à l’utilisation de « Composer » pour faire les mises à jour.

Quelles sont les bonnes pratiques à respecter pour sécuriser votre site Web avec Drupal ?

Un autre point important pour assurer une sécurité optimale de votre projet digital est de le développer dans le respect des bonnes pratiques. En effet, un projet qui ne les respecte pas risque tout simplement d’introduire des failles de sécurité, mais sera également plus compliqué à maintenir dans le temps.

Ces bonnes pratiques concernent différents aspects : le code et le paramétrage de Drupal, les processus et les outils à utiliser. Cette liste n’est pas exhaustive, n’hésitez pas à me suggérer d’autres bonnes pratiques sur LinkedIn, par exemple. 😉

Les bonnes pratiques côté « code » et « paramétrage »

Voici une liste, non exhaustive, des bonnes pratiques que je vous conseille d’appliquer dans vos projets Web sous Drupal :

• Respecter les conventions de développement de Drupal. En effet, un code à la syntaxe ou à l’indentation hétérogène est plus difficile à lire et à maintenir.
• Toujours privilégier les API internes de Drupal pour la manipulation de données et les relations avec la base de données. La plupart des besoins sont couverts par l’utilisation du module Entity API qui rajoute une couche d’abstraction sécurisée. Dans le cas où il est vraiment nécessaire d’interagir avec la base de données, il faut utiliser la Database API et les placeholders pour les données dynamiques servant à construire une requête.
• Ne jamais utiliser le filtre « raw » de Twig. C’est le seul cas où Twig ne nettoie pas les valeurs à printer.
• La validation des données. Valider et filtrer toutes les données provenant des utilisateurs pour prévenir les attaques d'injection.
• Mettre en place des Trusted Host Setting. Ce mécanisme issu de Symfony permet de se prémunir contre les usurpations de l'en-tête HTTP Host (spoofing). Voir la documentation officielle.
• Les modules de développement ne doivent jamais être activés sur des instances autres que la Dev. Ces derniers donnent énormément d’informations et sont des failles de sécurité évidentes avec (et parfois même sans) intrusion dans le back-office.
• Aucun formulaire ne doit être écrit directement en HTML. La Form API de Drupal normalise la validation et nettoie les soumissions.
• Utiliser des mécanismes d'authentification robustes tels que SAML ou OAuth, pour sécuriser l'accès au site.
• Contrôler l'accès pour les utilisateurs. Comment ? En utilisant des rôles et des autorisations Drupal pour gérer les privilèges d'accès.
• Mettre en place une gestion des mots de passe. Je vous recommande l’utilisation de mots de passe forts, combinés avec une politique de gestion des mots de passe, comme l'expiration régulière (1 fois par an ou plus fréquemment).
• Les formats de texte utilisables par les différents types d’utilisateur de votre site internet sont de potentielles failles majeures de sécurité. Il est nécessaire de limiter les balises HTML autorisées !
  Et pour les formats de texte plus permissifs, s’ils sont vraiment nécessaires, il faut aussi les limiter à des utilisateurs triés sur le volet.
• Drupal nous permet d’utiliser le format oEmbed pour les services compatibles. Cela permet d’intégrer des contenus externes dans son site, comme on le ferait avec une iframe.
  Pour les services non compatibles et pour lesquels il faut utiliser une iframe, une solution possible est de mettre en place une entité, comme un type de média ou de paragraphe, avec un champ « src » ainsi que des champs dédiés aux paramètres d’iframe sur lesquels vous auriez besoin de donner la main aux contributeurs. Il suffit ensuite de tester "programmatiquement” le contenu de ces champs pour limiter à un domaine précis, ou des valeurs valides pour les paramètres, et ensuite de reconstruire l’iframe à partir de ces valeurs. Cette pratique évite ainsi qu’un attaquant, ayant pris le contrôle d’un compte contributeur, puisse insérer des iframes dangereuses sur votre site.

Les bonnes pratiques niveau « Processus »

Je compléterai la liste précédente avec des points essentiels, mais pour le « Processus » cette fois-ci :

• Faire relire le code par un Lead développeur. Il sera garant de la sécurité.
• Appliquer le principe du Moindre Privilège, c’est-à-dire limiter les privilèges des utilisateurs et des modules à ce qui est strictement nécessaire. Appliquer ce principe minimisera les risques. Je compléterai ce principe avec : maintenir un nombre minimal de comptes administrateurs et enlever les utilisateurs inactifs.
• Monitorer le site Drupal à l’aide du tableau de bord du Core et du module contribué « Security Review ». Ces 2 outils vérifient des points cruciaux de sécurité, comme les droits des dossiers, l’utilisation des Trusted Host Pattern, etc.
• Le chiffrement des dumps de base de données via la commande drush « sql:sanitize » ou un module adéquat comme Entity Sanitizer.
• La sécurité des modules. Je vous conseille d’utiliser uniquement des modules Drupal provenant du référentiel officiel Drupal.org, ainsi que les mises à jour de ces derniers. Je vous recommande également de suivre les alertes de sécurité Drupal et de mettre à jour le site en conséquence. Et pour finir avec ce point, pensez à privilégier les modules couverts par l’équipe de sécurité.

Les bonnes pratiques pour les « Outils »

Pour finir cette longue liste, je vous propose quelques bonnes pratiques côté « Outils » :

• À chaque déploiement en Dev, le code est analysé par des outils détectant les CVE. Les rapports sont accessibles à tous et vérifiés chaque semaine ou avant chaque déploiement sur une instance externe, par le Lead Développeur du projet.
• Tous les développements sont versionnés sur Git et non accessibles à toute personne externe au projet. Un système de contrôle de version permet de suivre les modifications apportées au code et de revenir à des versions stables en cas de besoin.
• L’utilisation de « Composer » pour la gestion des dépendances. Cet outil accélère la récupération des mises à jour des dépendances.

Quels sont les modules essentiels pour maximiser la sécurité de votre site Web avec Drupal ?

Difficile de parler de Drupal et de la sécurité sans aborder la question des modules. Que ce soit pour dire qu’il ne faut pas utiliser des modules trouvés ailleurs que sur drupal.org, ou pour évoquer, comme nous allons le faire ici, les modules favorisant la sécurité de votre site.

Le module « Rename Admin Paths »

Le module Rename Admin Paths a pour but de sécuriser le back-office de Drupal en modifiant les chemins d'accès aux pages d’administration et de connexion.

Plus concrètement, il permet de renommer des urls :

• « /admin/... » en « /quelque-chose/... »
• et « /user/... » en « /encore-autre-chose/... »

Cela peut être efficace contre les robots de spam d'enregistrement par exemple, ou encore pour ralentir une tentative ciblée de hack.

Le module « Security review »

Security review est un module très simple à utiliser. En effet, après installation, il permet de lancer des vérifications sur 14 points de sécurité essentiels, comme les droits des dossiers et des fichiers, l’utilisation de formats de texte trop permissifs, ou encore la mise en place de règles pour les Trusted Host Pattern.

Il faut l’utiliser en production, car de nombreux points sont liés à l’infra et peuvent varier d’un environnement à un autre.

Ce module n'apporte pas automatiquement de modifications à votre site. C’est à vous ou à vos prestataires de faire les modifications nécessaires côté Drupal ou serveur.

Le module « Password Policy »

Le module Password Policy permet d'appliquer des restrictions sur les mots de passe des utilisateurs en définissant des règles.

Une politique de mot de passe peut être définie à l'aide d'un ensemble de contraintes qui doivent être respectées avant qu'un changement de mot de passe de l'utilisateur ne soit accepté. Chaque contrainte possède un paramètre permettant de définir le nombre minimum de conditions valides qui doivent être remplies avant que la contrainte ne soit satisfaite.

Le module met également en œuvre une fonction d'expiration du mot de passe. L'utilisateur est forcé de changer son mot de passe et est éventuellement bloqué lorsque son ancien mot de passe expire. Le tout en empêchant de réutiliser un ancien mot de passe. Souvenez-vous, j’avais déjà abordé ce point dans la liste des bonnes pratiques côté « code » et « paramétrage ».

Les administrateurs peuvent également obliger des utilisateurs spécifiques ou des rôles entiers à changer leur mot de passe lors de leur prochaine connexion.

Le module « Username Enumeration Prevention »

L'énumération des noms d'utilisateur est une technique utilisée par les acteurs malveillants pour identifier les noms d'utilisateur valides sur une application ou un site Web. Ces derniers peuvent ensuite être utilisés dans d'autres attaques, telles que le « credential stuffing ».

Concrètement, le module Username Enumeration Prevention empêche le formulaire de mot de passe oublié de Drupal d'afficher les messages suivants :

• « %nom est bloqué ou n'a pas encore été activé »
• « %nom n'est pas reconnu comme un nom d'utilisateur ou une adresse e-mail »

À la place des messages cités ci-dessus, il affiche un message identique, que le nom d’utilisateur soit existant ou non.

Ce module convertit également les réponses « 403 Access Denied » en réponses « 404 Not Found » sur les profils d'utilisateurs.

Mais pourquoi l’équipe de sécurité ne change-t-elle pas ce comportement ?

La raison est relativement simple : Drupal sert aussi à faire des sites internet où n’importe quel internaute peut s’inscrire et où son nom d’utilisateur peut être utilisé pour l’identifier en tant qu’auteur d’un contenu ou d’un commentaire. Avoir une liste de noms d’utilisateurs valides est alors simple et pas vraiment considéré comme une faille de sécurité potentielle. En fait, tout dépend des fonctionnalités d’un site.

Je vous partage le lien vers la page traitant de ce sujet par l’équipe de sécurité Drupal. Vous trouverez tous les détails de ce choix ainsi que des façons de se protéger... dont l’activation de ce module.

Le module « Antibot »

Antibot est un module Drupal léger, conçu pour empêcher les soumissions de formulaires robotisées sans nécessiter d'interaction de l'utilisateur final.

Il protège les formulaires en arrière-plan et ne nécessite que l'activation de JavaScript. Les formulaires protégés sont cachés si JavaScript n'est pas activé, avec un message d'activation nécessaire. Le module fonctionne en changeant l'action du formulaire, et en attente d'une interaction humaine avant de restaurer l'action correcte du formulaire.

Antibot génère également des clés uniques pour chaque formulaire, insérées automatiquement avec JavaScript pour empêcher les soumissions de formulaires à distance. Il est facile à configurer et marche particulièrement bien avec Webform.

Sur votre site Web, vous pouvez remplacer ce module par Honeypot qui est une alternative. Mais par expérience, je trouve ce module moins efficace.

Le module « Captcha »

Le module Captcha, comme son nom l’indique, permet d’ajouter des « Captcha » sur des formulaires.

Si vous ne savez pas ce qu’est un captcha, voici une définition : « captcha est un test de réponse à un défi, le plus souvent placé dans des formulaires Web, pour déterminer si l'utilisateur est humain ».

Le module propose de base des captcha très simples, mais il est également possible de rajouter différents types de challenges via des modules supplémentaires, pour utiliser par exemple :

• Google reCAPTCHA, mais il faudra faire attention au RGPD ;
• Cloudflare Turnstile, qui agit sans interaction comme dans l’image ci-dessous :

Le module « Entity Sanitizer »

Entity Sanitizer permet d’anonymiser les données d’un dump de base de données. Dans la plupart des cas, la commande Drush « sql:sanitize » suffit, car les seules données sensibles concernent les utilisateurs. En revanche, quand le site internet contient des contenus sensibles, dans un intranet par exemple, il est nécessaire de les « brouiller » dans le cas d’un export de la base de données.

C’est précisément ce que permet ce module en modifiant les valeurs de tous les champs pouvant contenir des données. Cela vous permet de réutiliser en toute sécurité les contenus des bases de données de production, sans exposer les données confidentielles.

Le module « ClamAV »

ClamAV est un antivirus OpenSource pouvant s’installer très facilement sur un serveur, et qui permet, entre autres, de scanner des fichiers pour détecter des virus.

Le module ClamAV de Drupal fait le lien avec cet antivirus et permet de vérifier que les fichiers téléchargés sur un site sont sains. Il empêche par conséquent l'enregistrement de fichiers infectés.

En conclusion

Ce qu’il faut retenir de cet article, c’est que la sécurité d'un site sous le CMS Drupal est un processus continu et multifactoriel. Il est crucial de maintenir à jour les versions du Core, des modules et des dépendances, en utilisant des outils comme « Composer ».

La mise en œuvre de bonnes pratiques, telles que le respect des conventions de développement, l'utilisation d'API internes, et la validation des données, est également essentielle pour garantir la sécurité de votre site Web.

De plus, l'utilisation de modules dédiés à la sécurité, tels que Rename Admin Paths, Security Review, Password Policy, Username Enumeration Prevention, Antibot, Captcha, Entity Sanitizer et ClamAV, renforce la protection contre les menaces en ligne.

En combinant toutes ces mesures, et en restant informés des mises à jour et des meilleures pratiques, les mainteneurs de sites internet développés sous Drupal peuvent réduire les risques de vulnérabilités et assurer la sécurité de leur plateforme Web.

Source : (1) Rapport annuel 2022 produit par SiteLock
Crédit photo : Blue Planet Studio