Récemment, une faille critique a été découverte sur les sites sous Drupal 6, 7 et 8 ouvrant la porte à des attaques massives (https://www.programmez.com/actualites/drupal-touche-par-une-faille-hautement-critique-27369)).

Parmi les sites qui ont été touchés, certains demeurent très difficiles à remettre sur pied. Cela ne garantit pas non plus une infiltration qui étend la vulnérabilité du site même après avoir mis à jour les patchs de sécurité. Par ailleurs, il reste également compliqué d’en trouver la cause et d’identifier les éléments malveillants qui résident.

Jusqu’à la version 7 de Drupal, les contenus introduits par les utilisateurs et la configuration du site étaient tous deux présents au sein de la base de données. Très opaque à décomposer lors d’une analyse, il est par conséquent complexe d’évaluer le temps pour une réparation complète.

Si l’on décompose les éléments que constituent une instance standard de Drupal, ce dernier-comprend :

• Le cœur de Drupal et les modules de contribution qui proviennent de la communauté,
• La configuration du site qui constitue la manière dont il est structuré,
• Les modules et le(s) thème(s) personnels, dit « custom » qui ont été développés spécifiquement pour le site et qui devraient impérativement être versionnés afin d’en maîtriser leurs évolutions,
• Les informations (contenus) qui ont été introduits
• Les fichiers annexes aux contenus et présents généralement dans le dossier "files" ou "private"

A la suite d’une attaque, si un site web présente des anomalies, on va tenter de rechercher quelles données ou fichiers ont été modifiée ou alors opter pour la solution de « backup » en récupérant une version précédente du site au moment de sa dernière sauvegarde. La deuxième option demeure la plus rapide et intéressante lorsque les contenus sont rarement mis à jour. Malheureusement, cela ne garantit pas que le site ait été infecté depuis longtemps sans que personne ne s’y soit rendu compte.

Sous Drupal 8, la configuration du site est également mélangée au contenu et stockés au sein de la même base de données, mais celle-ci à l’avantage de pouvoir être à tout moment exportée ou importée au format yaml, un format lisible. Cela offre la possibilité de versionner aisément l’évolution d’une configuration et des modules ou thèmes "custom". Par ailleurs, l’utilisation de composer permet également, à l’aide d’un fichier, de rétablir le téléchargement du cœur et des modules/thèmes de la communauté en une seule ligne de commande. Si bien qu’un site « vide » contenant une structure identique à l’existant peut être redéployé rapidement.

Ainsi, il ne reste donc que les informations propres au site ainsi que les fichiers annexes. Pour ces derniers, il s’agit en général de fichiers pdf, images ou autres formats standards très simple à analyser avec l’aide d’un anti-virus. Enfin les données, quant à elles, peuvent être en tout temps migrées d’un site à un autre grâce au module « migrate », cette opération sera certainement la plus longue, mais affranchit en revanche la lourde analyse que peut constituer la recherche d’un malware qui n’aboutit pas toujours à la résolution du problème.

Au final, même si Drupal a montré ses faiblesses depuis les deux "Drupalgeddons" survenus en 2014 et 2018, ces possibilités que nous offrent la nouvelle version constitue un net avantage en termes de sécurité et de récupération suite à une intrusion. En outre, les opérations précitées peuvent être bien plus facilement chiffrées et garantissent un résultat au final.