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 là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.
Jaap 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 !
Veuillez cliquer sur le lien ci-dessous et télécharger le PDF de cette ressource.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez consulter le rapportVeuillez réserver une démonstration.
Jaap 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 !
Table des matières
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior là pour aider votre organisation à sécuriser le code tout au long du cycle de développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable de la sécurité des applications, développeur, responsable de la sécurité informatique ou toute autre personne impliquée dans la sécurité, nous pouvons aider votre organisation à réduire les risques associés à un code non sécurisé.
Veuillez réserver une démonstration.TéléchargerRessources pour vous aider à démarrer
Thèmes et contenus de formation sur le code sécurisé
Notre contenu de pointe évolue constamment pour s'adapter à l'évolution constante du paysage du développement de logiciels tout en tenant compte de votre rôle. Des sujets couvrant tout, de l'IA à l'injection XQuery, proposés pour une variété de postes, allant des architectes aux ingénieurs en passant par les chefs de produit et l'assurance qualité. Découvrez un aperçu de ce que notre catalogue de contenu a à offrir par sujet et par rôle.
La Chambre de commerce établit la norme en matière de sécurité à grande échelle axée sur les développeurs
La Chambre de commerce néerlandaise explique comment elle a intégré le codage sécurisé dans le développement quotidien grâce à des certifications basées sur les rôles, à l'évaluation comparative du Trust Score et à une culture de responsabilité partagée en matière de sécurité.
%20(1).avif)
.avif)
Modélisation des menaces avec l'IA : transformer chaque développeur en modélisateur de menaces
Vous repartirez mieux équipé pour aider les développeurs à combiner les idées et les techniques de modélisation des menaces avec les outils d'IA qu'ils utilisent déjà pour renforcer la sécurité, améliorer la collaboration et créer des logiciels plus résilients dès le départ.
Ressources pour vous aider à démarrer
Cybermon est de retour : les missions Beat the Boss sont désormais disponibles sur demande.
Cybermon 2025 : Vaincre le Boss est désormais accessible toute l'année dans SCW. Mettez en œuvre des défis de sécurité avancés liés à l'IA et au LLM afin de renforcer le développement sécurisé de l'IA à grande échelle.
Explication de la loi sur la cyber-résilience : implications pour le développement de logiciels sécurisés dès leur conception
Découvrez les exigences de la loi européenne sur la cyber-résilience (CRA), à qui elle s'applique et comment les équipes d'ingénieurs peuvent se préparer grâce à des pratiques de sécurité dès la conception, à la prévention des vulnérabilités et au renforcement des capacités des développeurs.
Facilitateur 1 : Critères de réussite clairement définis et mesurables
Enabler 1 inaugure notre série en 10 parties intitulée « Enablers of Success » en démontrant comment associer le codage sécurisé à des résultats commerciaux tels que la réduction des risques et la rapidité afin d'assurer la maturité à long terme des programmes.
