Coders Conquer Security : Série Partage & Apprentissage - Injection NoSQL

Les bases de données NoSQL deviennent de plus en plus populaires. Difficile de nier leur rapidité et leur facilité de gestion des données non structurées, surtout avec des équipes de développement adoptant des méthodologies de plus en plus agiles.

Il faut du temps aux développeurs pour identifier les vulnérabilités et les défis liés aux technologies émergentes. Ce n'est qu'après une utilisation prolongée dans des applications en production que les problèmes commencent à faire surface.

Il en va de même pour les bases de données NoSQL. Les développeurs doivent être conscients des risques majeurs afin de sécuriser leurs applications. L'un de ces risques est l'injection NoSQL.

Examinons ce qu'est l'injection NoSQL, les dommages qu'elle peut causer et comment y remédier :

Comprendre l'injection NoSQL

L'injection NoSQL est causée par bon nombre des mêmes vulnérabilités d'injection que l'injection XML ou SQL.

L'injection NoSQL permet aux attaquants d'insérer des commandes arbitraires dans une requête NoSQL. Cela leur permet de voler des données et même de modifier la base de données si leurs privilèges sont suffisamment élevés.

Lorsqu'une application intègre directement des données contrôlées par l'utilisateur dans une expression de requête NoSQL, ces expressions utilisent souvent des fonctions ou des opérateurs intégrés qui peuvent être manipulés pour voler ou modifier des données. Et lorsqu'une telle manipulation est effectuée avec des intentions malveillantes, les conséquences peuvent être désastreuses.

Les bases de données MongoDB sont l'un des terrains de jeu les plus prisés pour exploiter cette vulnérabilité. L'opérateur « $ne: "" » est l'équivalent de « 1=1 » dans le monde SQL. Par exemple, un attaquant pourrait insérer les caractères « $ne: "" » dans les champs nom d'utilisateur et mot de passe d'une interface. Si le code est vulnérable à l'injection NoSQL, la base de données recherchera tous les enregistrements où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Aïe.

Si cette base de données n'est pas chiffrée, l'attaquant pourrait voler les noms d'utilisateur et les mots de passe de chaque utilisateur. Cela inclut les identifiants des administrateurs, leur offrant un accès total à l'ensemble de la base de données.

Les attaquants tentent souvent de transmettre des valeurs toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans des propriétés définies comme des fonctions.

Par exemple, MongoDB utilise une fonction « find » qui accepte un objet avec une propriété appelée « $where ». La propriété « $where » est définie par une fonction qui doit s'évaluer comme vraie ou fausse. Si cette fonction est modifiée de quelque manière que ce soit par une saisie utilisateur, une injection NoSQL est probablement présente.

Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article InfoQ.

Comprendre pourquoi l'injection NoSQL est dangereuse

L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.

Les impacts de l'injection NoSQL sont très similaires à ceux de l'injection SQL traditionnelle. Les données peuvent être volées ou modifiées, les comptes peuvent être compromis par le vol d'informations et, plus grave encore, les données pourraient être totalement effacées si une commande de suppression est exécutée avec succès.

En fin de compte, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. « No SQL » ne signifie pas « pas d'injections ».
Heureusement, certains membres de la communauté commencent à s'en rendre compte et à faire passer le message. Davantage de développeurs doivent se former pour protéger leurs applications contre des menaces méconnues qui peuvent devenir un véritable casse-tête si elles sont exploitées.

Contrer les injections NoSQL

Les injections NoSQL peuvent être difficiles à contrer. Malheureusement, il n'existe pas d'option de requêtes paramétrées comme c'est le cas pour les injections SQL. Cependant, ce n'est pas impossible. Voici quelques options pour vous aider :

• Les fuzzers peuvent être utilisés comme méthode de détection des vulnérabilités. Toutefois, comme pour beaucoup de choses, l'approche la plus simple est souvent la plus efficace. Ici, une bonne vieille revue de code reste votre meilleur allié.
• Lors de la revue de code, recherchez les endroits où une saisie utilisateur pourrait définir la valeur d'une expression ou modifier une fonction. Ne permettez jamais aux saisies utilisateur de modifier vos requêtes.
• Veillez à convertir les saisies utilisateur dans le type approprié. S'il s'agit d'un nombre, convertissez-le en nombre ; s'il s'agit d'une chaîne, convertissez-la en chaîne, et ainsi de suite.
• N'utilisez jamais $where ou des fonctions d'évaluation similaires avec des saisies utilisateur. Dans la plupart des cas, vous pouvez contourner ce problème en modifiant votre modèle de données ou votre schéma.
• Essayez d'utiliser Mongoose comme pilote pour MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne.
• Sécurisez votre base de données ! Créez des comptes utilisateurs à privilèges restreints, limitez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité en vigueur dans votre organisation.

L'un des inconvénients de la facilité d'utilisation des bases de données NoSQL est la tendance des développeurs à les déployer et à les utiliser sans se soucier de la sécurité.

Il est essentiel de prendre le temps d'apprendre à déployer une base de données NoSQL de manière sécurisée et à vous protéger contre les injections NoSQL.

Par exemple, MongoDB Enterprise Edition dispose de fonctionnalités avancées de contrôle d'accès pour vos documents. Appliquer le principe du « moindre privilège » peut constituer une excellente stratégie de défense en profondeur (DiD) si quelqu'un venait à découvrir une vulnérabilité dans votre application.

En résumé, voici ce qu'il faut retenir :

• Assainissez vos entrées avant de les utiliser dans une expression de requête NoSQL
• Utilisez des pilotes qui vous facilitent la tâche, comme Mongoose
• Effectuez des revues de code qui examinent spécifiquement la manière dont les données d'entrée sont utilisées dans les requêtes
• Utilisez des fuzzers et des scanners pour tenter de détecter les vulnérabilités dans votre code.

NoSQL ne signifie pas « pas d'injections »

Les bases de données NoSQL gagnent rapidement en popularité grâce à leur évolutivité et à leur rapidité de mise en place. La nouveauté de cette technologie peut conduire les développeurs à utiliser ces bases de données sans réfléchir à la manière de les sécuriser.

Les bases de données NoSQL peuvent être tout aussi vulnérables aux attaques par injection que les bases de données SQL. Soyez donc prudent et surveillez vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.

Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. C'est aussi simple que ça !

Vous pensez être prêt à localiser, identifier et corriger une injection NoSQL dès maintenant ? Entrez dans l'arène du code sécurisé, guerrier :

C'est tout pour 2018 ! Il s'agit de notre dernier article de l'année, mais nous serons de retour avec le prochain guide « Coders Conquer Security » le 10 janvier 2019. À bientôt !