Les 10 principales vulnérabilités du web et comment les éviter avec Drupal

27 novembre 2019
Les 10 principales vulnérabilités du web et comment les éviter avec Drupal

Découvrez les principales vulnérabilités du web telles que listées par l’OWASP, comprenez leurs enjeux et apprenez des moyens de vous en prémunir dans vos projets Drupal. Le retour sur la conférence de Ayesh Karunaratne.
 

OWASP (Open Web Application Security Project) est une communauté en ligne partageant des outils, documents et méthodes libres pour la sécurisation des applications web. Elle publie régulièrement des rapports permettant d’évaluer les plus fréquentes vulnérabilités rencontrées dans le web, propose des solutions pour garantir la sécurité des applications et données et assure son l’intégrité face à l’évolution des menaces.

 

Liste des 10 principales failles informatiques

Les 10 principales menaces répertoriées par la communauté OWASP sont globalement inchangées depuis des années. Les premières d’entre elles existent depuis plus de 10 ans et sont toujours les principales raisons de vulnérabilités à ce jour. C’est pourquoi il est important de comprendre ces menaces pour s’en prémunir.

  1. Les injections (en particulier dans le cas de Drupal les injections SQL)
  2. Le cross site scripting (XSS)
  3. L’exposition de données sensibles
  4. La défaillance d’authentification
  5. La défaillance de contrôle d’accès
  6. La désérialisation non sécurisée
  7. Les entités XML externes (XXE)
  8. L’usage de composants à vulnérabilités connues
  9. Les mauvaises configurations de sécurité
  10. La journalisation insuffisante

 

Comment éviter les failles informatiques avec Drupal ?

Source principale des menaces

Tous les CMS et frameworks du marché offrent des solutions de sécurisation des données, de hachage des mots de passe, de cryptage, etc. Dans ces conditions pourquoi les applications web sont toujours les cibles de tiers malveillants qui parviennent à leurs fins ?
Tout le monde commet des erreurs. Aucun système ne peut prémunir d’un oubli ou d’une erreur d’implémentation et d’architecture. Dans l’histoire de la communauté Drupal un exemple marquant est celui du premier événement sécuritaire connu sous le nom de « Drupalgeddon », à l’époque détecté sur Drupal 7.
Cette ligne de code a existé dans le core de drupal pendant des années, une erreur, simple, qui a été l’une des vulnérabilités majeures du CMS jusqu’à sa détection en 2014.
 

 

Cette faille a été très simplement corrigée de la sorte (un correctif simple pour une erreur bête).
 

Plus d’information sur la faille Drupalgeddon.
 

La principale vigilance que tout développeur, architecte ou concepteur d’application doit garder à l’esprit est la suivante : ne JAMAIS faire confiance à une saisie utilisateur ou à une source de données externe.

 

Cette vigilance s’étend à tout ce qui peut être modifié par un tiers extérieur à l’application : les soumissions de formulaires, les arguments d’URL, les chemins d’URL, les enregistrements de bases de données, les uploads d’utilisateurs, les e-mails entrants, les cookies, les headers http, les enregistrements DNS, les enregistrements WHOIS, les variables d’environnements, etc. Tout ce qui vient de l’extérieur de l’application est une menace potentielle.

Valider, nettoyer, échapper

Lutter contre les injections et le cross site scripting nécessite de revenir à trois notions fondamentales qui disposent de nombreux outils au sein de Drupal : valider, nettoyer et échapper les données.
Une injection est une tentative d’insertion de requête, au sein d’un champ de saisie par exemple. Elle a pour objectif de tromper le code de traitement de ce champs de saisie pour le forcer à exécuter une requête qui n’était pas prévue initialement dans la conception de l’application.

 

De la même façon, le cross site scripting, abrégé XSS, est une tentative d’insertion de code pour forcer l’application à exécuter une logique qui n’était pas prévue initialement dans la conception. 

 

Les entités XML externes (XXE) sont assez similaires dans l’esprit. Elles permettent de lire un contenu externe, comme un fichier par exemple, et d’en faire un rendu lors de l’exécution du XML. Un tiers mal intentionné peut utiliser une saisie XML pour chercher à atteindre des fichiers critiques de l’application et récupérer des données sensibles de la sorte.

 

Une désérialisation non sécurisée se produit lorsqu’une action de désérialisation (par exemple via la fonction unserialize() de PHP) est réalisée sur un contenu externe qui peut contenir des éléments malicieux susceptibles d’être exécutés au moment où la logique applicative traite la chaîne sérialisée.

 

Pour toutes ces vulnérabilités la notion primordiale citée en introduction est la clé de la protection : ne pas faire confiance à la saisie de l’utilisateur, quelle qu’elle soit ! Il est donc nécessaire de valider, nettoyer et échapper tout ce qui pourrait être malicieux, soit tout ce qui ne provient pas de l’application elle-même.
Valider les données saisies par l’utilisateur permet de refuser le traitement de la saisie dès le point d’entrée, tant que celle-ci ne correspond pas à un standard établi (par exemple on s’assurer qu’un champ attendant une adresse mail ne contient vraiment qu’une adresse mail et rien d’autre).

example@example.com
Example-example
https//example.com

 

Drupal met à disposition plusieurs services de validation permettant de s’assurer de la validité des données saisies par un utilisateur. De plus, l’usage des components Symfony permet également d’hériter d’un ensemble de validators très complets : https://api.drupal.org/api/drupal/8.8.x/search/validator

 

En dernier recours PHP met également à disposition des validators : https://www.php.net/manual/en/filter.filters.validate.php.

 

Nettoyer les données saisies par l’utilisateur permet de supprimer tout ce qui pourrait être considéré comme malicieux dans la saisie avant usage dans la logique applicative. Le nettoyage peut être une suppression des tags HTML, de caractères spécifiques, etc.

 

How to <script>alert(‘xss’);</script>       >       How to
How to <script>alert(‘xss’);</script>       >       How to alert(‘xss’);
my-awesome-song-*****.mp3                   >       my-awesome-song-_____.mp3
my-class>your-class                                 >       my-class_your-class

 

Échapper les données, permet de neutraliser les caractères sensibles d’une chaîne de caractères potentiellement malicieuse en limitant l’apparence finale de la chaîne.
 

How to <script>alert(‘xss’);</script>       >      How to &lt;script&gt;alert(\‘xss\’);&lt;/script&gt;

Drupal met à disposition un ensemble de méthodes de nettoyage et d’échappement qui permettent de réaliser des traitements de ce type sur des chaînes de caractères : https://api.drupal.org/api/drupal/core!includes!common.inc/group/sanitization/8.8.x

 

De même, l’API de Drupal permet de gérer la sécurité des requêtes SQL en utilisant les tableaux de placeholders : https://www.drupal.org/docs/8/api/database-api/static-queries.
 

 

En dernier recours PHP met également à disposition des filtres permettant de nettoyer et d’échapper des caractères : https://www.php.net/manual/tr/filter.filters.sanitize.php
 

Une fois ces premières règles en place quelques actions complémentaires peuvent être prises contre ces types de vulnérabilité.


Injections


Il est important de se rappeler que les headers HTTP ou headers d’e-mail sont vulnérables aux injections également et devraient toujours être traités avec la même vigilance que les exemples précédents.
Il est impératif de n’autoriser l’accès à la base de données qu’à un utilisateur disposant de privilèges réduits et surtout pas à l’utilisateur root de la base de données. Les permissions doivent être choisies avec soin et adaptées aux opérations attendues dans la base de données.
Enfin le conseil de bon sens qu’il est important de rappeler est que la saisie par un utilisateur d’informations techniques telles que du code PHP, javascript ou des requêtes SQL doivent être bannis dans une application web, même en backoffice pour des utilisateurs éduqués, car ce sont des portes ouvertes pour de potentiels tiers malveillants.

 
Cross-site scripting (XSS)


Avant de faire un rendu de valeurs provenant d’un utilisateur (via un template, une vue, etc) l’échappement de caractères est impératif.
Lors de l’usage de cookies, ceux contenants des données sensibles doivent toujours être marqués selon le contexte HTTP-Only. Ainsi, une tentative de récupération de données malicieuse se verrait échouer par script.
Pour limiter l’exécution de scripts au seul domaine courant de l’application il est possible d’utiliser les headers CSP (Content-Security-Policy). Cela limitera fortement les dégâts qu’un tiers malicieux pourrait occasionner au sein du domaine en question.
Pour éviter la contribution de scripts dans les champs de texte il est préférable d’utiliser des solutions telles que le langage Markdown pour remplacer l’usage de champs Full HTML dans lesquels un script pourrait être inséré. Ce type de langage de mise en forme n’est, en effet, pas compatible avec l’usage de scripts.
Lors de l’écriture de code custom, toujours favoriser l’usage de l’API pour nettoyer les chaînes et surtout considérer tout usage de la fonction strip_tags() de PHP comme une vulnérabilité car elle ne retire que les tags mais pas les attributs qui peuvent également contenir du code malicieux.


Désérialisation non sécurisée


Il faut toujours considérer ce qui ressort des fonctions PHP serialize() et unserialize() comme étant non sécurisé. Il ne faut jamais désérialiser une saisie d’utilisateur tiers et reposer autant que possible sur l’usage de JSON pour des échanges de données de ce type.
Il est possible de contrôler des données sérialisées en utilisant HMAC pour détecter d’éventuelles modifications sur la chaîne réellement traitées par l’application.


Entités XML externes (XXE)


Pour ce type de vulnérabilité, la plupart du temps la fonctionnalité XML elle-même n’étant pas réellement nécessaire ont peut se contenter de la désactiver directement dans PHP  via la fonction libxml_disable_entity_loader() ou même de configurer les parsers XML pour interdire le traitement de sources externes.
Une excellente protection contre ce type d’injection est également de forcer un schéma XML pour empêcher la récupération de sources non prévues dans le schéma.

 

Auteur : Nicolas Loye, Directeur Technique
 

Rubrique