Iconos SCW
héroe bg sin separador
Blog

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

Jaap Karan Singh
Publicado el 20 de diciembre de 2018
Última actualización el 8 de marzo de 2026

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 !

Mostrar el recurso
Mostrar el recurso

Les bases de données NoSQL sont de plus en plus populaires. Il est difficile de nier leur rapidité et leur facilité de traitement des données non structurées, mais à mesure que leur utilisation se généralise, de nouvelles vulnérabilités apparaissent inévitablement.

¿Desea obtener más información?

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Más información

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Reserve una demostración
Compartir en:
marcas de LinkedInSocialx logotipo
Autor
Jaap Karan Singh
Publicado el 20 de diciembre de 2018

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Compartir en:
marcas de LinkedInSocialx logotipo

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 !

Mostrar el recurso
Mostrar el recurso

Rellene el siguiente formulario para descargar el informe.

Nos gustaría obtener su autorización para enviarle información sobre nuestros productos y/o sobre temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el mayor cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Icono de éxito de SCW
Icono de error scw
Para enviar el formulario, active las cookies «Analytics». No dude en desactivarlas de nuevo una vez que haya terminado.

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 !

Ver el seminario web
Comience
Más información

Haga clic en el enlace siguiente y descargue el PDF de este recurso.

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Mostrar el informeReserve una demostración
Descargar el PDF
Mostrar el recurso
Compartir en:
marcas de LinkedInSocialx logotipo
¿Desea obtener más información?

Compartir en:
marcas de LinkedInSocialx logotipo
Autor
Jaap Karan Singh
Publicado el 20 de diciembre de 2018

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Compartir en:
marcas de LinkedInSocialx logotipo

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 !

Índice

Descargar el PDF
Mostrar el recurso
¿Desea obtener más información?

Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Más información

Secure Code Warrior aquí para ayudar a su organización a proteger el código a lo largo de todo el ciclo de desarrollo de software y a crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es responsable de la seguridad de las aplicaciones, desarrollador, responsable de la seguridad informática o cualquier otra persona involucrada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código no seguro.

Reserve una demostraciónDescargar
Compartir en:
marcas de LinkedInSocialx logotipo
Centro de recursos

Recursos para ayudarle a empezar

Más publicaciones
Centro de recursos

Recursos para ayudarle a empezar

Más publicaciones