Comment Drupal est protégé contre les 10 plus importantes failles de sécurité

Dans le domaine de la sécurité, la réputation de Drupal n'est plus à faire. Interrogé sur les raisons de cette réputation, il est souvent indiqué que Drupal est sécurisé by design, c'est à dire depuis sa conception même. Autrement dit, dès le départ, Drupal a été conçu avec la notion toujours présente à l'esprit que le système doit être sûr et sécurisé.

L'OWASP, organisation à but non lucratif dont l'objectif est d'améliorer la sécurité des logiciels, disposant d'une autorité reconnue mondialement en matière de sécurité sur Internet, publie chaque année un Top 10 des failles de sécurité des applications web les plus critiques. Ce Top 10 est largement accepté comme étant un référent sur l'état de l'art en matière de sécurité sur Internet .

Dries Buytaert, le fondateur de Drupal, affirme que Drupal de par sa conception est protégé contre ce Top 10 des failles de sécurité publiée par l'OWASP. Regardons en détail comment Drupal, grâce à ses interfaces de programmations (API) si elles sont utilisées correctement, prend en compte chacune de ces plus importantes failles. Ces éléments de réponse proviennent du rapport publié régulièrement sur drupalsecurityreport.org.

1. Injection

Une faille d'injection, telle l'injection SQL, OS et LDAP, se produit quand une donnée non fiable est envoyée à un interpréteur en tant qu'élément d'une commande ou d'une requête. Les données hostiles de l'attaquant peuvent duper l'interpréteur afin de l'amener à exécuter des commandes fortuites ou accéder à des données non autorisées.

Comment Drupal répond à cette faille de sécurité ?

Drupal contient une API de base de données orientée objet robuste qui rend difficile pour les développeurs de créer sans le savoir des trous d'injection, par la désinfection automatique des paramètres de la requête.

2. Violation de Gestion d'Authentification et de Session

Les fonctions applicatives relatives à l'authentification et la gestion de session ne sont souvent pas mises en oeuvre correctement, permettant aux attaquants de compromettre les mots de passe, clés, jetons de session, ou d'exploiter d'autres failles d'implémentation pour s'approprier les identités d'autres utilisateurs.

Comment Drupal répond à cette faille de sécurité ?

Les comptes d'utilisateurs et l'authentification sont gérées par le noyau Drupal. Les cookies d'authentification et le nom, l'ID et le mot de passe d'un utilisateur sont gérés sur le serveur pour empêcher un utilisateur d'escalader facilement une autorisation. Les mots de passe des utilisateurs sont hachés en utilisant un algorithme basé sur le Portable PHP Password Hashing Framework et les sessions existantes sont détruites lors de la connexion et déconnexion.

3. Cross-Site Scripting (XSS)

Les failles XSS se produisent chaque fois qu'une application accepte des données non fiables et les envoie à un navigateur web sans validation appropriée. XSS permet à des attaquants d'exécuter du script dans le navigateur de la victime afin de détourner des sessions utilisateur, défigurer des sites web, ou rediriger l'utilisateur vers des sites malveillants.

Comment Drupal répond à cette faille de sécurité ?

Drupal dispose d'un solide système de filtrage du contenu généré sur la page. Le contenu non fiable à destination des internautes est filtré pour éliminer les éléments dangereux par défaut. Pour les développeurs, Drupal dispose d'au moins huit fonctions de l'API pour filtrer le contenu généré et empêcher ainsi les attaques XSS.

4. Références directes non sécurisées à un objet

Une référence directe à un objet se produit quand un développeur expose une référence à un objet d'exécution interne, tel un fichier, un dossier, un enregistrement de base de données ou une clé de base de données. Sans un contrôle d'accès ou autre protection, les attaquants peuvent manipuler ces références pour accéder à des données non autorisées.

Comment Drupal répond à cette faille de sécurité ?

Le système de contrôle d'accès et le riche éco-système des autorisations de Drupal empêchent l'exécution des requêtes non autorisées. Les méthodes de contrôle d'accès sont disponibles via la configuration et le code contribué par la communauté. En outre, la protection contre les attaques sémantiques est mise en œuvre dans le noyau Drupal via l'API des formulaires.

5. Mauvaise configuration et Sécurité

Une bonne sécurité nécessite de disposer d'une configuration sécurisée définie et déployée pour l'application, contextes, serveur d'application, serveur web, serveur de base de données et la plate-forme. Tous ces paramètres doivent être définis, mis en oeuvre et maintenus, car beaucoup ne sont pas livrés sécurisés par défaut. Cela implique de tenir tous les logiciels à jour.

Comment Drupal répond à cette faille de sécurité ?

Beaucoup de risques critiques, tels que l'accès au compte administrateur, aux formats de texte, et à des informations privées, sont limités à un seul compte admin par défaut. Les défauts d'ergonomie identifiés qui peuvent mèner à une mauvaise configuration sont identifiés par des tests récurrents d'utilisabilité, et des correctifs sont inclus au coeur de Drupal. Une documentation sur les meilleures pratiques pour une configuration sécurisée et la conception d'un site Drupal est fournie et mise à jour gratuitement sur drupal.org. Plusieurs modules contribués permettent d'effectuer une revue générale automatisée de la sécurité d'un site, et d'autres proposent de mettre en œuvre des configurations mieux sécurisées.

6. Exposition de données sensibles

Beaucoup d'applications web ne protègent pas correctement les données sensibles telles que les cartes de crédit, identifiants d'impôt et informations d'authentification. Les pirates peuvent voler ou modifier ces données faiblement protégées pour effectuer un vol d'identité, de la fraude à la carte de crédit ou autres crimes. Les données sensibles méritent une protection supplémentaire tel un chiffrement statique ou en transit, ainsi que des précautions particulières lors de l'échange avec le navigateur.

Comment Drupal répond à cette faille de sécurité ?

Les mots de passe de compte sont hachés à plusieurs reprises sur la base du Portable PHP Password Hashing Framework. Plusieurs modules contribués de Drupal proposent des solutions pour crypter les données sensibles qu'elles soient au repos ou en transit.

7. Manque de contrôle d’accès au niveau fonctionnel

Pratiquement toutes les applications web vérifient les droits d'accès au niveau fonctionnel avant de rendre cette fonctionnalité visible dans l'interface utilisateur. Cependant, les applications doivent effectuer les mêmes vérifications de contrôle d'accès sur le serveur lors de l'accès à chaque fonction. Si les demandes ne sont pas vérifiées, les attaquants seront en mesure de forger des demandes afin d'accéder à une fonctionnalité non autorisée.

Comment Drupal répond à cette faille de sécurité ?

Les accès fonctionnels dans Drupal sont protégés par un puissant système de permissions qui vérifie si les autorisations sont appropriées avant de déclecnher quelque action. Pour les accès aux URL, la vérification d'accès est étroitement intégré aussi bien dans le menu de rendu et que dans le système de routage système, ce qui signifie que la visibilité des liens de navigation et des pages sont protégées par le même système de permissions qui gère les droits d'accès aux requêtes.

8. Falsification de requête intersite (CSRF)

Une attaque CSRF (Cross Site Request Forgery) force le navigateur d'une victime authentifiée à envoyer une requête HTTP forgée, comprenant le cookie de session de la victime ainsi que toute autre information automatiquement inclue, à une application web vulnérable. Ceci permet à l'attaquant de forcer le navigateur de la victime à générer des requêtes dont l'application vulnérable pense qu'elles émanent légitimement de la victime.

Comment Drupal répond à cette faille de sécurité ?

Drupal valide les intentions de l'utilisateur dans les actions effectuées en utilisant les techniques standard de l'industrie. Les actions typiques avec effets secondaires (telles que les actions qui suppriment des objets de base de données) sont généralement effectuées avec la méthode HTTP POST. L'API des formulaires de Drupal met en œuvre des jetons uniques de protection contre les CSRF dans les requêtes POST. Les actions moins importantes (dangereuses) peuvent tirer parti de la génération de jetons et de validation des fonctions fournies par l'API des formulaires tout en utilisant une requête HTTP GET.

9. Utilisation de composants avec des vulnérabilités connues

Les composants vulnérables, tels que bibliothèques, contextes et autres modules logiciels fonctionnent presque toujours avec des privilèges maximum. Ainsi, si exploités, ils peuvent causer des pertes de données sérieuses ou une prise de contrôle du serveur. Les applications utilisant ces composants vulnérables peuvent compromettre leurs défenses et permettre une série d'attaques et d'impacts potentiels.

Comment Drupal répond à cette faille de sécurité ?

Les bibliothèques et framework inclus (il y a peu) dans le coeur de Drupal sont (au niveau du système) peu sophistiqués, et de faible risque pour une compromission du serveur ou de l'application.

10. Redirections et renvois non validés

Les applications web réorientent et redirigent fréquemment les utilisateurs vers d'autres pages et sites internet, et utilisent des données non fiables pour déterminer les pages de destination. Sans validation appropriée, les attaquants peuvent réorienter les victimes vers des sites de phishing ou de malware, ou utiliser les renvois pour accéder à des pages non autorisées.

Comment Drupal répond à cette faille de sécurité ?

Les redirections internes au site ne peuvent pas être utilisées pour contourner le système de contrôle de menu et de contrôle d'accès intégré de Drupal. Drupal est protégé également contre la redirection automatique vers des URL hors site qui pourraient être utilisés dans une attaque de phishing.

En guise de conclusion

Avec ce tour d'horizon détaillé, on peut comprendre désormais pourquoi Drupal dispose d'une solide réputation en matière de sécurité. Bien entendu, ces mesures de sécurité ne peuvent être efficaces que si le site Drupal est réalisé dans le respect de ses API et de l'état de l'art. C'est pourquoi le choix d'un spécialiste Drupal pour la réalisation de votre projet doit être réalisé avec soin.

Certes, c'est très bien, mais Drupal est-il sécurisé ? pourriez-vous me demander. Je pourrais vous répondre brièvement Vous connaissez un logiciel infaillible ? La sécurité est moins un dogme qu'un processus continue de veille et d'amélioration. Un logiciel peut être sécurisé un jour pour devenir vulnérable le lendemain. Pour approfondir cette réponse je vous invite à lire la mise en perspective et les enseignements tirés d'une vulnérabilité détectée sur Drupal (sa-core-2014-005).

Ce billet est une traduction libre et agrémentée de Drupal and the top-10 of security flaws. et d'une partie du Drupal Security Report (version 1.3) de mars 2014.

Mise à jour le 11 juillet 2014 : pour aller plus loin sur les aspects de sécurité gérés par Drupal, vous pouvez consulter cet article : Ideas to help keep your Drupal project secure against the OWASP Top 10