Blog

Les codeurs à la conquête de la sécurité : série Share & Learn - Injection NoSQL

December 20, 2018
Jaap Karan Singh

Les bases de données NoSQL sont de plus en plus populaire. Il est difficile de nier leur rapidité et leur facilité de traitement des données non structurées, en particulier lorsque les équipes de développement utilisent des méthodologies de plus en plus agiles.

Il faut du temps aux développeurs pour éliminer les vulnérabilités et les autres défis liés aux technologies émergentes. Ce n'est qu'après un certain temps d'utilisation dans les applications de production que les problèmes commencent à apparaître.

Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients des principaux risques pour garantir la sécurité de leurs applications. L'injection NoSQL est l'un de ces risques.

Voyons ce qu'est l'injection NoSQL, quels dommages elle peut provoquer et comment y remédier :

Comprendre l'injection NoSQL

L'injection NoSQL est causée par de nombreuses vulnérabilités d'injection identiques, telles que XML ou Injection SQL.

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

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

Les bases de données MongoDB constituent l'un des terrains de jeu les plus populaires à exploiter avec cette vulnérabilité. « $ne : «" 'est l'opérateur équivalent à 1=1 dans le monde SQL, donc, à titre d'exemple, un attaquant pourrait placer les caractères « $ne : « » 'dans les champs nom d'utilisateur et mot de passe d'une interface utilisateur. Si le code est vulnérable à l'injection NoSQL, la base de données recherchera tous les enregistrements dont le nom d'utilisateur et le mot de passe ne correspondent pas à une chaîne vide. En d'autres termes : tous. Beurk.

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 qu'elle contient. Cela inclut le nom d'utilisateur et les mots de passe de l'administrateur, ce qui leur donne un accès illimité à l'ensemble de la base de données.

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

Par exemple, MongoDB utilise une fonction de recherche qui prend un objet avec une propriété appelée $where. La propriété $where est définie sur une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par une saisie utilisateur, une injection NoSQL s'y cache probablement.

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

Découvrez pourquoi l'injection NoSQL est dangereuse

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

Les impacts de l'injection NoSQL sont sensiblement les mêmes que ceux de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis en volant des données et, ce qui est peut-être le plus grave, les données peuvent être complètement 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. « Pas de code SQL » ne signifie pas qu'il n'y a pas d'injections.
Heureusement, certains membres de la communauté en prennent note et faire passer le mot. De plus en plus de développeurs doivent se renseigner pour protéger leurs applications contre des problèmes méconnus qui peuvent devenir un véritable casse-tête s'ils sont exploités.

Vaincre l'injection NoSQL

L'injection NoSQL peut être difficile à vaincre. Malheureusement, il n'est pas possible de paramétrer les requêtes comme c'est le cas avec l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :

  • Les fuzzers peuvent être utilisés comme méthode de détection des vulnérabilités. Bien que, comme c'est le cas pour de nombreuses choses dans la vie, l'approche la plus simple puisse être la plus efficace. Ici, la bonne vieille révision de code est votre meilleure alliée.
  • Lors de la révision du code, recherchez les endroits où une saisie utilisateur pourrait définir la valeur d'une expression ou modifier une fonction. N'autorisez pas l'utilisateur à modifier vos requêtes.
  • Assurez-vous de convertir les entrées de l'utilisateur dans la classe appropriée. S'il s'agit d'un nombre, convertissez-le en nombre, s'il s'agit d'une chaîne, convertissez-le en chaîne et ainsi de suite.
  • N'utilisez jamais $where ou des fonctions d'évaluation similaires avec les entrées utilisateur. Dans la plupart des cas, vous pouvez contourner ce problème en modifiant le modèle de données ou le schéma.
  • Essayez d'utiliser Mangouste comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous dites à Mongoose que vos entrées sont des chaînes, ils seront coulés sur des cordes. Ainsi, tous les objets transmis par un attaquant ne seront pas traités comme des objets, mais comme des chaînes.
  • Renforcez votre base de données ! Créez des comptes utilisateurs à privilèges réduits, optimisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité applicables à 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 installer et à commencer à les utiliser sans se soucier de la sécurité.

Il est essentiel que vous preniez le temps d'apprendre à configurer en toute sécurité une base de données NoSQL et à vous protéger des injections NoSQL.

Par exemple, Édition Enterprise de MongoDB dispose de fonctionnalités avancées de contrôle d'accès à vos documents. L'application du « moindre privilège » peut être une bonne stratégie de défense en profondeur (DiD) au cas où quelqu'un trouverait une vulnérabilité dans votre application.

Pour résumer, voici ce que nous avons :

  • Nettoyez votre entrée avant de l'utiliser dans une expression de requête NoSQL
  • Utilisez des pilotes qui vous aident, comme Mongoose
  • Réalisez 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 de votre code.

NoSQL n'est pas une injection

Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs fonctionnalités évolutives et de leur rapidité de configuration. La nouveauté de la technologie peut amener les développeurs à utiliser des bases de données NoSQL sans réfléchir à la manière de les sécuriser.

Les bases de données NoSQL peuvent être tout aussi vulnérables que les bases de données SQL aux attaques par injection. Soyez donc prudent et prêtez attention à vos requêtes. Si vous souhaitez en savoir plus, consultez notre Ressources pédagogiques ou testez vos compétences avec notre démo gratuite.

Préparez-vous à l'avance et vous n'aurez pas à vous soucier des injections NoSQL dans vos applications. C'est trop facile !

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 :

Et c'est terminé pour 2018 ! Ce sera notre dernier article de l'année, mais nous reviendrons avec le prochain guide Coders Conquer Security le 10 janvier 2019. À bientôt !

Slogan

Govern AI-driven development before it ships

Measure AI-assisted risk, enforce secure coding policy at commit, and accelerate secure delivery across your SDLC.

book a demo
Slogan

Explore more blogs

Lorem ipsum diam quis enim lobortis scelerisque fermentum dui faucibus in ornare quam viverra orci sagittis eu volutpat odio facilisis.

browse all
Case Study
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.

Learn More
Case Study
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

Security as culture: How Blue Prism cultivates world-class secure developers

Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed

Learn More
Case Study
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

One Culture of Security: How Sage built their security champions program with agile secure code learning

Discover how Sage enhanced security with a flexible, relationship-focused approach, creating 200+ security champions and achieving measurable risk reduction.

Learn More
Blog
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

Named in the Gartner® Hype Cycle™ for Application Security 2026

Secure Code Warrior is named in the Gartner® Hype Cycle™ for Application Security, 2026 for Agentic Coding Security and Secure Coding Training. Here's why.

Learn More
Blog
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

Are you a CISO or Engineering Leader worried about the Security and Cost of LLM code generation?

Review the SCW AI Trust Index, our proprietary LLM benchmarking data, before going all-in on an AI model.

Learn More
Blog
Filter Label
This is some text inside of a div block.
This is some text inside of a div block.

Enabler 6: Regular Reporting to Leadership

Executive buy-in doesn't sustain itself. Enabler 6 shows how regular reporting keeps leadership engaged, informed, and invested in program success.

Learn More

Secure AI-driven development before it ships

See developer risk, enforce policy, and prevent vulnerabilities across your software development lifecycle.

Réserver une démo
trust score
No items found.