Analyse de la sécurité du code Drupal

09.09.2021

Dans les parties précédentes, nous nous sommes concentrés sur la configuration de Drupal et la vue d'ensemble des modules et bibliothèques. Dans la troisième partie de la série sur la réalisation d'un audit de sécurité, nous nous concentrerons sur la vue d'ensemble des modules et thèmes personnalisés. Nous effectuerons un audit du dépôt du projet, identifierons et analyserons les éléments sur lesquels il vaut la peine de prêter attention pendant le processus d'audit.

Vue d'ensemble des thèmes et modules Drupal personnalisés

Dans les thèmes et modules Drupal personnalisés, les vecteurs d'attaque sont les plus susceptibles d'apparaître. Il s'y trouve du code qui n'est pas largement utilisé, contrairement au code pour les modules et thèmes contrib. Par conséquent, il n'est pas si bien testé en termes de sécurité. Dans cet article, je discuterai d'une liste de contrôle de base utilisée pour auditer le code Drupal personnalisé. Cette liste peut être utilisée comme base pour un audit des modules et thèmes personnalisés.

Routage

Nous commencerons par l'analyse des paramètres reçus de l'utilisateur. Vérifions quel est leur type et comment ils sont filtrés. Drupal permet d'utiliser des paramètres dans les routages. Ce sont des valeurs dynamiques, dont un traitement incorrect peut créer des vecteurs d'attaque. Si une requête est créée sur la base d'un paramètre et non filtrée, cela peut causer un vecteur d'attaque de type SQL Injection, par exemple.

Ensuite, nous devrions examiner la configuration d'accès au routage, plus précisément – les permissions que l'utilisateur doit avoir pour obtenir l'accès. Lors de la déclaration du routage, nous devons définir les exigences que l'utilisateur doit remplir pour accéder au routage. Nous devons analyser les permissions requises pour chaque routage spécifié dans notre code Drupal personnalisé et considérer si leur niveau est approprié. Spécifier un niveau de permissions trop bas ou incorrect entraînera un accès des utilisateurs à des pages auxquelles ils ne devraient pas avoir accès. Cela peut être à la fois les pages listant les articles sur votre page et les pages listant tous les utilisateurs avec toutes les données assignées à un compte donné. Pour cette raison, l'audit des permissions est si important.

Formulaires

Tout d'abord, nous analyserons la conformité des types d'éléments et vérifierons si le bon type pour un champ donné a été utilisé. Lors de l'analyse des types de champs utilisés dans le formulaire, nous pouvons rencontrer un champ dont le nom et la description suggèrent qu'il devrait être rempli avec des données d'un type spécifique. Cependant, la définition du champ peut permettre au champ d'être rempli avec d'autres types de données. Nous devons nous assurer que la définition du type d'éléments correspond à leur objectif.

La prochaine étape sera d'analyser les méthodes utilisées pour valider les valeurs de champ dans le formulaire. Drupal permet de définir des méthodes personnalisées qui valident la validité des données saisies. Nous devrions tester la validité des méthodes de validation personnalisées et nous assurer que seules les données valides passent la validation.

La dernière chose sera de vérifier la présence et l'utilisation correcte de l'API de formulaire fournie par Drupal. Nous devrions analyser la manière d'utiliser l'API de formulaire, de préférence en utilisant la documentation, et nous assurer que les formulaires sont créés comme indiqué.

La documentation spécifie :

les cas où l'utilisation d'un type de champ donné est correcte,
comment créer les méthodes de validation,
comment utiliser hook_form_alter,
comment créer des formulaires pour être intuitifs pour l'utilisateur.

Requêtes SQL

Commençons par vérifier la présence et l'utilisation correcte de l'API de base de données fournie par Drupal. Elle est équipée de méthodes offrant une sécurité contre les attaques sur la base de données. L'utilisation correcte de l'API protège largement contre les attaques. Nous devons particulièrement prêter attention à l'utilisation des méthodes de filtrage des données d'entrée dans les requêtes SQL. Drupal recommande d'utiliser des placeholders s'il est nécessaire d'utiliser des données d'entrée, par exemple, à partir d'une variable dont la valeur a été spécifiée par l'utilisateur dans le formulaire. Voici un exemple :

$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = ‘ . $foo[‘name’]);

Dans le code ci-dessus, nous voyons que la valeur 'name' du tableau $foo est attribuée à la requête sans filtrage. Dans de tels cas, je recommande d'utiliser des placeholders.

$foo = $this->getFormData(); $query = \Database::getConnection()->query(‘SELECT foo FROM {bar} b WHERE b.name = :name’, [‘:name’ => $foo[‘name’]]);

En créant les requêtes de cette manière, nous soumettons la variable $foo ['name'] à un filtrage, ce qui protégera la requête contre les attaques de type SQL Injection.

Mécanismes de filtrage

Cela signifie vérifier la présence et la justesse du filtrage des données reçues de l'utilisateur. Nous devons vérifier que seul TWIG est utilisé pour rendre les variables dans les modèles, qui par défaut filtre le contenu des variables et s'assure qu'elles sont sûres. Dans le cas de travail avec des variables qui sont ensuite utilisées dans des chaînes traduisibles, nous devons nous assurer que ces variables sont remplacées par les placeholders appropriés. Le texte brut provenant de l'utilisateur devrait être filtré en utilisant la méthode Html::escape() si l'utilisateur ne doit pas pouvoir fournir de balises HTML dans le texte et la fonction Xss::filterAdmin() s'il doit pouvoir le faire. Si l'utilisateur fournit des liens, ils devraient aussi être filtrés.

Les fonctions utilisées à cet effet sont UrlHelper::stripDangerousProtocols() et UrlHelper::filterBadProtocol(). Les mécanismes de filtrage sont également applicables du côté du client. Pour nettoyer le texte en JavaScript, nous devrions utiliser la fonction Drupal.checkPlain().

Données sensibles

Nous devrions vérifier si le code ne contient pas d'identifiants ou de clés API. Dans certains cas, nous pouvons tomber sur des identifiants laissés dans le code des modules personnalisés. Les identifier ne demande pas beaucoup de travail.

Révision du dépôt

Il vaut la peine de jeter un coup d'œil au dépôt pour chercher des informations sensibles qui pourraient être stockées dans les fichiers. La première étape est d'analyser le fichier settings.php et de s'assurer qu'il n'y a pas d'identifiants qui donneraient accès à la base de données ou à d'autres composants du site Drupal. Ensuite, passons en revue les fichiers des variables d'environnement et assurons-nous qu'il n'y a pas d'identifiants dedans. Les identifiants requis par l'environnement ne doivent pas faire partie du dépôt.

L'étape suivante est de vérifier s'il n'y a pas de fichiers confidentiels profondément cachés, par exemple – avec des clés privées SSL ou des copies ou dumps de la base de données. Parfois, les fichiers qui ne devraient jamais se trouver dans le dépôt y entrent par erreur. Certains d'entre eux sont, par exemple, des dumps de bases de données ou des clés privées. Les identifier et les éliminer est recommandé.

Analyse du code Drupal – résumé

Dans la troisième partie de la série sur la réalisation d'un audit de sécurité Drupal, nous avons appris les moyens de vérifier le code des modules et thèmes personnalisés, nous avons audité le dépôt du projet afin de nous assurer qu'aucune donnée sensible n'était publiquement disponible, et nous avons analysé les éléments sur lesquels il vaut la peine de prêter attention pendant le processus d'audit.

Appliquer les conseils que j'ai publiés dans cet article rendra votre application plus sécurisée. Un audit du code est un élément clé menant à une meilleure sécurité de la page. Il exige plus de temps et de connaissances que la mise à jour que nous avons couverte dans la première partie et la configuration correcte de Drupal que nous avons couverte dans la deuxième partie de la série, mais les avantages de le faire sont bien plus précieux que le temps passé à le faire.

Dans la prochaine partie de cette série d'articles, nous découvrirons des outils externes pour automatiser le processus d'audit. C'est la prochaine étape réalisée dans un audit de sécurité complet. Avez-vous besoin d'aide pour réaliser une telle tâche ? Notre équipe de support Drupal a une vaste expérience dans la conduite des audits.