Les codeurs conquièrent la sécurité : Série "Partageons et apprenons" - Injection NoSQL
Les bases de données NoSQL sont de plus en plus populaires. Il est difficile de nier leur rapidité et leur facilité à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.
Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.
Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.
Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :
Comprendre l'injection NoSQL
L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou 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 prennent souvent des fonctions ou ont 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 sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par 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 où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.
Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.
Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme 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 comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.
Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.
Pourquoi l'injection NoSQL est-elle dangereuse ?
L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.
Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.
En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu 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 d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :
- Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
- Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
- Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
- N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
- Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
- Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.
La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.
Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.
Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.
Pour résumer, voici ce que nous avons :
- Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
- Utilisez des pilotes qui vous aident, comme Mongoose
- Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
- Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.
NoSQL n'est pas No Injections
Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à 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, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.
Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !
Vous pensez être prêt à localiser, identifier et réparer 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 billet pour l'année, mais nous serons de retour 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é à traiter des données non structurées, mais à mesure que leur utilisation se généralise, de nouvelles vulnérabilités remontent inévitablement à la surface.
Jaap Karan Singh est un évangéliste du codage sécurisé, Chief Singh et cofondateur de Secure Code Warrior.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é.
Réservez 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 populaires. Il est difficile de nier leur rapidité et leur facilité à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.
Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.
Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.
Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :
Comprendre l'injection NoSQL
L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou 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 prennent souvent des fonctions ou ont 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 sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par 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 où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.
Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.
Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme 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 comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.
Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.
Pourquoi l'injection NoSQL est-elle dangereuse ?
L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.
Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.
En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu 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 d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :
- Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
- Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
- Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
- N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
- Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
- Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.
La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.
Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.
Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.
Pour résumer, voici ce que nous avons :
- Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
- Utilisez des pilotes qui vous aident, comme Mongoose
- Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
- Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.
NoSQL n'est pas No Injections
Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à 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, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.
Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !
Vous pensez être prêt à localiser, identifier et réparer 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 billet pour l'année, mais nous serons de retour 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é à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.
Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.
Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.
Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :
Comprendre l'injection NoSQL
L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou 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 prennent souvent des fonctions ou ont 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 sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par 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 où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.
Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.
Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme 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 comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.
Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.
Pourquoi l'injection NoSQL est-elle dangereuse ?
L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.
Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.
En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu 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 d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :
- Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
- Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
- Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
- N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
- Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
- Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.
La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.
Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.
Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.
Pour résumer, voici ce que nous avons :
- Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
- Utilisez des pilotes qui vous aident, comme Mongoose
- Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
- Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.
NoSQL n'est pas No Injections
Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à 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, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.
Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !
Vous pensez être prêt à localiser, identifier et réparer 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 billet pour l'année, mais nous serons de retour avec le prochain guide Coders Conquer Security le 10 janvier 2019. À bientôt !
Cliquez sur le lien ci-dessous et téléchargez le PDF de cette ressource.
Secure Code Warrior est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é.
Voir le rapportRéservez 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 populaires. Il est difficile de nier leur rapidité et leur facilité à traiter les données non structurées, en particulier pour les équipes de développement qui travaillent selon des méthodologies de plus en plus agiles.
Il faut du temps aux développeurs pour éliminer les vulnérabilités et autres difficultés des technologies émergentes. Ce n'est qu'après avoir été utilisée pendant un certain temps dans des applications de production que les problèmes commencent à remonter à la surface.
Les bases de données NoSQL sont similaires. Les développeurs doivent être conscients de certains risques clés afin de garantir la sécurité de leurs applications. L'un de ces risques est l'injection NoSQL.
Voyons ce qu'est une injection NoSQL, quels sont les dommages qu'elle peut causer et comment y remédier :
Comprendre l'injection NoSQL
L'injection NoSQL est causée par un grand nombre des mêmes vulnérabilités d'injection telles que l'injection XML ou 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 prennent souvent des fonctions ou ont 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 sont l'un des terrains de jeu les plus populaires pour exploiter cette vulnérabilité. "$ne : """ est l'opérateur équivalent à 1=1 dans le monde SQL. Ainsi, par 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 où le nom d'utilisateur et le mot de passe ne sont pas égaux à une chaîne vide. En d'autres termes : tous. Vous avez raison.
Si cette base de données n'est pas cryptée, l'attaquant peut voler les noms d'utilisateur et les mots de passe de chacun des utilisateurs qu'elle contient. Cela inclut les noms d'utilisateur et les mots de passe des administrateurs, ce qui leur donne un accès illimité à l'ensemble de la base de données.
Les attaquants tentent souvent d'introduire des valeurs qui sont toujours vraies. Une autre attaque courante consiste à injecter du code malveillant dans les propriétés définies comme 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 comme une fonction qui doit être évaluée à true ou false. Si cette fonction est modifiée de quelque manière que ce soit par l'utilisateur, il est probable qu'une injection NoSQL s'y cache.
Pour un aperçu détaillé des subtilités de l'injection NoSQL, consultez cet article d'InfoQ.
Pourquoi l'injection NoSQL est-elle dangereuse ?
L'injection NoSQL est dangereuse principalement parce qu'elle n'a pas encore reçu l'attention qu'elle mérite de la part de la communauté de la sécurité.
Les conséquences de l'injection NoSQL sont sensiblement les mêmes que celles de l'injection SQL traditionnelle. Des données peuvent être volées ou modifiées, des comptes peuvent être compromis par le vol de données et, ce qui est peut-être le plus grave, des données peuvent être complètement effacées si une commande d'effacement est lancée avec succès.
En définitive, MongoDB et les autres moteurs de base de données NoSQL sont vulnérables aux attaques. "Pas de SQL" ne signifie pas pas d'injections.
Heureusement, certains membres de la communauté en prennent note et font passer le message. Davantage de développeurs doivent s'informer afin de pouvoir protéger leurs applications contre des dangers peu 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 d'utiliser des requêtes paramétrées comme dans le cas de l'injection SQL. Cependant, ce n'est pas impossible. Il existe quelques options pour vous aider :
- Les fuzzers peuvent être utilisés comme une méthode pour détecter les vulnérabilités. Cependant, comme c'est le cas pour beaucoup de choses dans la vie, l'approche la plus simple peut être la plus efficace. Dans ce cas, le bon vieil examen du code est votre meilleur allié.
- Lorsque vous révisez le code, recherchez les endroits où l'entrée de l'utilisateur pourrait fixer la valeur d'une expression ou modifier une fonction. Ne permettez pas à l'utilisateur de modifier vos requêtes.
- Veillez à attribuer à l'entrée de l'utilisateur la classe qui lui revient. Si c'est un nombre, transformez-le en nombre, si c'est une chaîne, transformez-la en chaîne et ainsi de suite.
- N'utilisez jamais $where ou d'autres fonctions d'évaluation similaires en même temps que les données saisies par l'utilisateur. Dans la plupart des cas, vous pouvez contourner le problème en modifiant le modèle de données ou le schéma.
- Essayez d'utiliser Mongoose comme pilote MongoDB. Mongoose vous permet de définir un schéma pour votre base de données NoSQL. Si vous indiquez à Mongoose que vos entrées sont des chaînes, elles seront converties en chaînes. Ainsi, tout objet transmis par un attaquant ne sera pas traité comme un objet, mais comme une chaîne de caractères.
- Renforcez votre base de données ! Créez des comptes utilisateurs à faibles privilèges, maximisez le temps d'exécution des requêtes et suivez toujours les meilleures pratiques de sécurité qui s'appliquent à votre organisation.
La facilité d'utilisation des bases de données NoSQL a pour inconvénient que les développeurs ont tendance à les mettre en place et à les utiliser sans se soucier de la sécurité.
Il est essentiel que vous preniez le temps d'apprendre à mettre en place une base de données NoSQL en toute sécurité et à vous protéger contre les injections NoSQL.
Par exemple, MongoDB Enterprise Edition dispose de capacités avancées de contrôle d'accès à vos documents. L'application du principe du "moindre privilège" peut constituer une bonne stratégie de défense en profondeur au cas où quelqu'un découvrirait une vulnérabilité dans votre application.
Pour résumer, voici ce que nous avons :
- Assainissez vos données avant de les utiliser dans une expression de requête NoSQL.
- Utilisez des pilotes qui vous aident, comme Mongoose
- Effectuer des revues de code portant spécifiquement sur la manière dont les données d'entrée sont utilisées dans les requêtes.
- Utilisez des fuzzers et des scanners pour essayer de trouver des vulnérabilités dans votre code.
NoSQL n'est pas No Injections
Les bases de données NoSQL gagnent rapidement en popularité en raison de leurs caractéristiques évolutives et de leur rapidité d'installation. La nouveauté de la technologie peut conduire les développeurs à utiliser les bases de données NoSQL sans penser à 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, alors agissez avec prudence et faites attention à vos requêtes. Si vous souhaitez en savoir plus, consultez nos ressources d'apprentissage ou testez vos compétences avec notre démo gratuite.
Préparez-vous à l'avance et vous n'aurez plus à vous soucier des injections NoSQL dans vos applications. Trop facile !
Vous pensez être prêt à localiser, identifier et réparer 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 billet pour l'année, mais nous serons de retour 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 est là pour vous aider à sécuriser le code tout au long du cycle de vie du développement logiciel et à créer une culture dans laquelle la cybersécurité est une priorité. Que vous soyez responsable AppSec, développeur, CISO 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é.
Réservez une démonstrationTéléchargerRessources pour vous aider à démarrer
Évaluation comparative des compétences en matière de sécurité : Rationalisation de la conception sécurisée dans l'entreprise
Le mouvement "Secure-by-Design" (conception sécurisée) est l'avenir du développement de logiciels sécurisés. Découvrez les éléments clés que les entreprises doivent garder à l'esprit lorsqu'elles envisagent une initiative de conception sécurisée.
DigitalOcean réduit sa dette de sécurité avec Secure Code Warrior
L'utilisation par DigitalOcean de la formation Secure Code Warrior a considérablement réduit la dette de sécurité, permettant aux équipes de se concentrer davantage sur l'innovation et la productivité. L'amélioration de la sécurité a renforcé la qualité des produits et l'avantage concurrentiel de l'entreprise. À l'avenir, le score de confiance SCW les aidera à améliorer leurs pratiques de sécurité et à continuer à stimuler l'innovation.
Ressources pour vous aider à démarrer
Sécurité réactive contre sécurité préventive : La prévention est un meilleur remède
L'idée d'apporter une sécurité préventive aux codes et systèmes existants en même temps qu'aux applications plus récentes peut sembler décourageante, mais une approche "Secure-by-Design", mise en œuvre en améliorant les compétences des développeurs, permet d'appliquer les meilleures pratiques de sécurité à ces systèmes. C'est la meilleure chance qu'ont de nombreuses organisations d'améliorer leur sécurité.
.png)
Les avantages de l'évaluation des compétences des développeurs en matière de sécurité
L'importance croissante accordée au code sécurisé et aux principes de conception sécurisée exige que les développeurs soient formés à la cybersécurité dès le début du cycle de développement durable, et que des outils tels que le Trust Score de Secure Code Warriorles aident à mesurer et à améliorer leurs progrès.
Assurer le succès des initiatives de conception sécurisée de l'entreprise
Notre dernier document de recherche, Benchmarking Security Skills : Streamlining Secure-by-Design in the Enterprise est le résultat d'une analyse approfondie d'initiatives réelles de conception sécurisée au niveau de l'entreprise, et de l'élaboration d'approches de meilleures pratiques basées sur des conclusions fondées sur des données.
Plongée en profondeur : Naviguer dans la vulnérabilité critique de CUPS dans les systèmes GNU-Linux
Découvrez les derniers défis de sécurité auxquels sont confrontés les utilisateurs de Linux en explorant les récentes vulnérabilités de haute sévérité dans le système d'impression commun d'UNIX (CUPS). Apprenez comment ces problèmes peuvent conduire à une potentielle exécution de code à distance (RCE) et ce que vous pouvez faire pour protéger vos systèmes.
