Revue de la configuration de Drupal en termes de sécurité
Dans la première partie de la série sur les audits de sécurité Drupal, nous avons décrit comment examiner les modules et les bibliothèques. Cependant, les modules et les dépendances seront inutiles si un utilisateur peut voir notre routage personnalisé où nous affichons toutes les informations client. Par conséquent, dans cet article, nous examinerons la configuration de notre site web. Une configuration correcte est l'un des éléments clés influençant la sécurité.
Vérification de la configuration de Drupal
Pour cette partie, notre liste inclura la vérification des autorisations des rôles, l'accès aux vues et routages Drupal, entre autres. Nous vérifierons également la correction de la configuration des formats de texte et nous effectuerons d'autres contrôles pour identifier le plus grand nombre de vecteurs d'attaque potentiels sur notre application.
Audit des autorisations des rôles
En allant sur /admin/people/roles, nous verrons la liste de tous les rôles disponibles.
Dans la liste à droite (la colonne OPERATIONS), après avoir cliqué nous pouvons sélectionner l'option modifier les autorisations, ce qui nous redirigera vers la page /admin/people/permissions/[nom_de_machine_du_rôle] (exemple pour le rôle Anonyme : /admin/people/permissions/anonymous). Après être allé dans la modification des autorisations, Drupal listera toutes les permissions possibles qui ont été accordées pour le rôle sélectionné.
Pour vérifier les autorisations, nous devrions d'abord considérer quelle tâche est assignée au rôle. Nous devons nous demander si le rôle X devrait avoir la permission pour l'action Y, par exemple : le rôle de rédacteur de contenu devrait-il pouvoir modifier toutes les vues ? Si la réponse est non, les autorisations devraient être restreintes.
Une connaissance complète du projet est requise pour un audit des autorisations. Si nous trouvons une autorisation que nous estimons qu'un rôle donné ne devrait pas avoir, nous devrions seulement informer dans le rapport d'audit de la possibilité d'un rôle ayant des autorisations facultatives. Nous fournirons plus d'informations sur la façon de créer un bon rapport dans l'un des prochains articles de la série sur les audits de sécurité Drupal.
Audit des autorisations des vues
Après avoir audité les rôles, il est temps de jeter un œil aux vues. Elles sont toutes listées sous /admin/structure/views.
Notre première tâche, dans ce cas, sera d'entrer dans la modification de chaque vue qui fournit un routage. Nous devons trouver la section PARAMÈTRES DE LA PAGE, et plus précisément - l'option Accès, qui ne devrait être intentionnellement réglée que sur "Non restreint".
Comme c'est le cas pour les rôles, lors de l'audit des autorisations des vues, nous devrions nous demander : quelles restrictions devraient être imposées à la vue X ? Si la vue doit être accessible à tout le monde, il est bon de pratiquer l'utilisation d'une restriction qui nécessite la permission d'accéder au contenu publié. Si l'une des vues n'a pas de restrictions ou si nous les trouvons trop modérées, nous devrions en informer dans le rapport.
Audit des fichiers routing.yml dans les modules personnalisés
En ce qui concerne les routages créés dans les modules personnalisés, l'audit est similaire. Nous devrions examiner chaque fichier *.routing.yml pour nous assurer que chaque routage a le niveau de sécurité approprié. Voici un exemple de déclaration de nouveau routage
Dans ce cas, chaque utilisateur ayant la permission d'accès au contenu est autorisé à accéder à la page /machine_name/transliterate. Il est également bon de définir dans ce cas un niveau d'accès minimum pour chaque routage d'accès au contenu.
Audit des formats de texte
Le chemin /admin/config/content/formats contient tous les formats de texte disponibles sur la page. Dans ce cas, l'audit consistera à vérifier, par exemple, s'il n'est pas possible d'insérer du code JavaScript à l'aide d'un format de texte donné ou s'il n'est pas possible de lier une image qui sera téléchargée depuis une autre page. Il est également important que la liste des extensions de fichiers possibles ne permette pas de télécharger des fichiers avec des extensions non sécurisées si cela n'est pas nécessaire. Bien sûr, nous signalons les erreurs de configuration - le niveau de risque dépend du type d'erreur.
Audit de la journalisation des erreurs
Il existe l'option de configuration Messages d'erreur à afficher sur la page /admin/config/development/logging. Elle est utilisée pour définir le niveau d'affichage des erreurs. Cette option doit être réglée sur Aucun sur la page de production. Si cette option est réglée sur une variante autre que Aucun dans l'environnement de production, nous la signalons comme une menace de faible niveau.
Audit de la connexion de base
Il existe deux façons pour le panneau de connexion d'informer si l'utilisateur essayant de se connecter a fourni des données incorrectes. Il peut donner une réponse brève comme "les données sont incorrectes", ou donner une information lorsque le login est incorrect, et une autre lorsque le mot de passe est incorrect. Dans le dernier cas, nous faisons face à un vecteur pour une attaque de force brute. L'attaquant peut d'abord forcer les logins puis les mots de passe - accédant ainsi aux comptes utilisateur.
Un autre aspect qui mérite d'être vérifié est la politique de mot de passe. C'est un sujet controversé, car certains proposent de forcer un changement de mot de passe périodiquement, et d'autres disent que le mot de passe devrait contenir au moins une majuscule, une minuscule, un chiffre et un caractère spécial. Certaines personnes combinent ces deux règles, et les utilisateurs finissent par créer des mots de passe comme Juillet2021! qui répondent à toutes les exigences. Ma recommandation personnelle dans ce cas exclut la nécessité de changer le mot de passe de temps en temps. Déterminer la complexité du mot de passe est recommandé, mais la chose la plus importante est sa longueur - plus le mot de passe est long, plus il prendra du temps à être craqué. La politique de mot de passe est une question qui dépend du type de projet et doit être analysée individuellement. Dans le cas d'une politique de mot de passe faible, vous devez la signaler comme une menace avec un niveau dépendant de la gravité de la politique.
Audit des formulaires
Les formulaires devraient être protégés contre le spam. Ils devraient être créés en utilisant l'API Drupal dans la mesure du possible. Vérifiez si les formulaires sont protégés contre le spam et si leur validation ne permet pas l'entrée de données incorrectes ou dangereuses. Si vous trouvez une inexactitude dans la configuration du formulaire, vous devriez la signaler – le niveau de risque dépend de la situation. Il y aura un niveau de risque différent pour un potentiel SQLi, et pour la possibilité d'entrer des données incorrectes – par exemple dans la liste de sélection.
Recommandations supplémentaires
Il existe des modules Drupal qui augmentent la sécurité de notre application. L'un de ces modules est Security Kit. Grâce à lui, vous réduirez la probabilité d'exploitation des failles de sécurité du site web. Ce module offre Anti-XSS, Anti-CSRF, Anti-ClickJacking, et d'autres mesures de sécurité. Nous recommandons de lire l'article lié et de considérer l'installation.
Security Review est un module qui peut aider avec un audit de sécurité Drupal. Il utilise des tests de sécurité automatisés qui aident à réaliser l'audit.
Ce module :
- vérifie les autorisations des fichiers,
- effectue un audit des formats de fichiers,
- réalise un audit des options responsables de la signalisation d'erreurs,
- effectue un audit des options, dans lequel nous déterminons quelles extensions de fichiers peuvent être téléversées (par exemple pour être téléchargées dans un article de blog),
- surveille les erreurs de base de données afin de détecter une potentielle attaque,
- surveille le panneau de connexion dans le même but,
- vérifie la configuration du fichier des hôtes de confiance,
- vérifie les autorisations des vues.
Security Review est recommandé car il peut accélérer le processus d'audit de la page.
Configuration Drupal vérifiée - et ensuite ?
Dans cette partie de la série sur la réalisation d'un audit de sécurité Drupal, nous avons appris les façons de vérifier la configuration de Drupal. Nous sommes familiers avec les options de configuration qui peuvent ouvrir des vecteurs d'attaque et nous savons quelles sont les recommandations pour fermer ces vecteurs.
Acquérir les connaissances fournies dans cet article vous a permis de mieux comprendre qu'une configuration correcte de Drupal est aussi importante que le maintenir à jour. Un audit de configuration est une autre des activités que nous effectuons lors d'un audit de sécurité - notre équipe de support Drupal recommande une vérification complète de la configuration lors d'un audit de sécurité.
Dans la prochaine partie de cette série d'articles, nous aborderons le code et apprendrons les moyens de l'auditer. Nous présenterons les façons d'analyser les modules et thèmes. Nous examinerons ce qu'il y a dans le dépôt. Y a-t-il des mots de passe, des clés dedans ? Ou peut-être tout le dump de la base de données ?
