
Les codeurs à la conquête de la sécurité : série Share & Learn - Injection NoSQL
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 !


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.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.


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 !

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 !

Klicken Sie auf den untenstehenden Link und laden Sie das PDF dieser Ressource herunter.
Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht anzeigenDemo buchenJaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
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 !
Inhaltsverzeichnis
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.

Secure Code Warrior Ihr Unternehmen dabei, den Code während des gesamten Softwareentwicklungszyklus zu sichern und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Ganz gleich, ob Sie für die Anwendungssicherheit verantwortlich sind, Entwickler, IT-Sicherheitsbeauftragter oder in einer anderen Funktion im Bereich Sicherheit tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Schulung zum sicheren Code
Unsere hochmodernen Inhalte werden ständig weiterentwickelt, um mit den ständigen Veränderungen in der Softwareentwicklungslandschaft Schritt zu halten und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für eine Vielzahl von Positionen konzipiert, von Architekten über Ingenieure bis hin zu Produktmanagern und Qualitätssicherungsmitarbeitern. Verschaffen Sie sich einen Überblick über die Inhalte unseres Katalogs, sortiert nach Themen und Rollen.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die missions „Beat the Boss“ sind jetzt auf Abruf verfügbar.
Cybermon 2025 Beat the Boss ist jetzt das ganze Jahr über in SCW verfügbar. Setzen Sie fortschrittliche Sicherheitsherausforderungen im Zusammenhang mit KI und LLM ein, um die sichere Entwicklung von KI in großem Maßstab zu stärken.
Erläuterung des Gesetzes zur Cyberresilienz: Was bedeutet das für die Entwicklung sicherer Software bereits ab der Konzeption?
Entdecken Sie, was das europäische Gesetz zur Cyberresilienz (CRA) verlangt, für wen es gilt und wie sich Ingenieurteams durch Sicherheitsmaßnahmen bereits in der Entwurfsphase, durch die Vermeidung von Schwachstellen und durch die Stärkung der Fähigkeiten der Entwickler darauf vorbereiten können.
Moderator 1: Definierte und messbare Erfolgskriterien
Enabler 1 gibt den Startschuss für unsere 10-teilige Serie mit dem Titel „Enablers of Success“ und zeigt, wie sichere Codierung mit geschäftlichen Ergebnissen wie Risikominderung und Schnelligkeit kombiniert werden kann, um die langfristige Reife von Programmen sicherzustellen.




%20(1).avif)
.avif)
