Valider / nettoyer / échapper les données sur Drupal

Un niveau de sécurité maximal pour vos données Drupal 

Dans l’ensemble des failles de sécurité que l’on rencontre aujourd’hui lors du développement d’applications web, les plus fréquentes sont également parmi les plus anciennes du classement OWASP. Il existe un ensemble de règles et de vigilances simples à mettre en œuvre pour s’en prémunir et assurer un niveau de sécurité suffisant pour traiter les cas de vulnérabilités les plus fréquemment rencontrés. Les points détaillés ci-après servent d’introduction et devraient permettre aux technicien(ne)s de comprendre les principes de base d’une programmation avec un degré de sécurité minimum.

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

\Drupal::service('email.validator')->isValid($mail);

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

filter_var($mail, FILTER_VALIDATE_EMAIL);

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

check_markup($text, 'filtered_html', '', array())

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.

$query = $connection->query("SELECT * FROM posts WHERE title = :title", [':title' => $query]);

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é.

 1. Les 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.

2. 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.

3. 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.

4. 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 on 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.

Conclusion

Ces premiers principes et leurs applications concrètes autour du CMS Drupal ne sont que des bases. Les différentes communautés de technicien(ne)s travaillant avec PHP en particulier ou le développement applicatif en général organisent des conférences partout dans le monde où des experts de la sécurité abordent de tels sujets plus en détail, consultez la section events de la communauté OWASP ou des différentes communautés de développement pour approfondir le sujet.

Dans tous les cas, la maîtrise des trois concepts de base, valider / nettoyer / échapper, le fait d’en faire un réflexe dans le développement, permettra d’obtenir un niveau de sécurité minimum dans vos applications, de tranquilliser vos clients et de vous tranquilliser en garantissant un niveau de qualité supérieur. Même s’ils ne suffisent pas à garantir le caractère sécuritaire d’une application à eux seuls, ils représentent des indispensables à ne jamais oublier.