Injection NoSQL : Quand s’éloigner de SQL ne signifie pas s’éloigner de l’injection 🍃

Dans le paysage en évolution des technologies de bases de données, de nombreuses organisations ont adopté les bases NoSQL pour leur flexibilité, leur évolutivité et leurs avantages en performance. MongoDB, Cassandra, Redis et d’autres solutions NoSQL sont devenues l’épine dorsale des applications modernes, alimentant tout, des réseaux sociaux aux systèmes IoT. Cependant, une idée fausse dangereuse persiste chez les développeurs : la croyance que les bases NoSQL sont intrinsèquement immunisées contre les attaques par injection. Cette fausse sécurité a créé un nouveau paysage de vulnérabilités que les attaquants exploitent de plus en plus.

Le mythe persistant de la sécurité NoSQL

La croyance que les bases NoSQL sont immunisées contre les injections est fausse, mais cette idée continue de mettre de nombreuses applications en danger. Lorsqu’ils migrent de bases SQL traditionnelles vers des alternatives NoSQL, les développeurs supposent souvent qu’ils laissent derrière eux les vulnérabilités d’injection. La réalité est bien plus complexe et préoccupante.

Une injection NoSQL est une attaque qui cible les bases NoSQL en exploitant des vulnérabilités dans la formulation des requêtes, avec pour but pour les attaquants de manipuler des requêtes non sécurisées pour contourner l’authentification ou voler des données. Le problème fondamental reste le même que pour l’injection SQL : les injections NoSQL proviennent de la concaténation directe d’entrées utilisateur non nettoyées dans une requête de base de données.

Comprendre les vulnérabilités d’injection NoSQL

Qu’est-ce qui différencie NoSQL ?

Contrairement aux bases SQL, où les injections sont basées sur des requêtes SQL telles que SELECT ou INSERT, les bases NoSQL utilisent des langages de requête spécifiques à chaque type de base. Cette diversité crée un défi : il n’existe pas d’approche universelle pour sécuriser les bases NoSQL, chaque plateforme ayant sa propre syntaxe, ses opérateurs et ses vecteurs d’attaque potentiels.

Les bases NoSQL ne supportent pas un langage de requête standardisé, et les requêtes exactes autorisées dépendent du moteur de base — par exemple, MongoDB, Cassandra, Redis ou Google Bigtable. Ce manque de standardisation oblige les développeurs à comprendre les implications de sécurité spécifiques à leur plateforme choisie.

Les deux principales formes d’injection NoSQL

Les deux formes principales d’injection NoSQL sont l’injection de syntaxe, où les attaquants manipulent la syntaxe de la requête comme pour l’injection SQL, et l’injection d’opérateurs, où ils exploitent les opérateurs de requête pour manipuler les requêtes.

Injection de syntaxe se produit lorsque les attaquants peuvent casser la syntaxe de la requête NoSQL et injecter leur propre charge utile. Pour identifier un point d’injection potentiel, il faut casser la syntaxe en cours ou injecter un opérateur et observer tout changement de réponse, comme des différences notables dans la longueur du contenu, le code de statut ou les en-têtes de réponse.

Injection d’opérateurs exploite les opérateurs de requête spécifiques aux bases NoSQL. Par exemple, dans MongoDB, des opérateurs comme $ne (pas égal), $gt (supérieur à), et $where peuvent être manipulés pour modifier la logique de la requête et contourner les contrôles de sécurité.

Scénarios d’attaque réels

Contournement d’authentification : l’attaque classique

Une des attaques NoSQL les plus courantes et dangereuses consiste à contourner les mécanismes d’authentification. Considérons une fonction de connexion typique qui vérifie les identifiants utilisateur :

Users.findOne({
  "name": req.body.name,
  "password": req.body.password
});

Puisque le paramètre du nom d’utilisateur provient d’un objet JSON désérialisé, il est possible pour un attaquant d’injecter des opérateurs de requête MongoDB pour manipuler la requête et effectuer un contournement de connexion.

Au lieu de fournir des identifiants légitimes, un attaquant peut soumettre :

{
  "name": {"$ne": "1"},
  "password": {"$ne": "1"}
}

L’opérateur $ne (pas égal) sera utilisé pour trouver le premier utilisateur dont le nom et le mot de passe ne sont pas égaux à la chaîne “1”. Étant donné que cette condition est pratiquement toujours vraie, l’attaquant contourne avec succès l’authentification et accède au système — généralement en tant que premier utilisateur dans la base, souvent un compte administrateur.

Compromission ciblée de comptes

Pour cibler un compte, vous pouvez construire une charge utile incluant un nom d’utilisateur connu, ou un nom d’utilisateur que vous avez deviné, par exemple en utilisant l’opérateur $in avec des noms d’administrateur courants. Cela permet aux attaquants de compromettre spécifiquement des comptes à haute valeur sans avoir besoin de crédentiels valides.

Exfiltration de données via injection JavaScript

Dans de nombreuses bases NoSQL, certains opérateurs ou fonctions de requête peuvent exécuter du code JavaScript limité, comme l’opérateur $where de MongoDB. Cela ouvre des opportunités pour des attaques plus sophistiquées.

En utilisant l’opérateur $where, les attaquants peuvent injecter du code JavaScript qui provoque un délai si leur condition correspond, permettant une exfiltration de données en aveugle. En testant systématiquement chaque caractère d’un mot de passe ou d’un champ sensible et en mesurant les temps de réponse, ils peuvent extraire des ensembles de données complets caractère par caractère.

Attaques d’injection de second ordre

Les injections NoSQL de second ordre sont un autre type où une entrée non nettoyée est injectée dans une application et stockée sans exécution immédiate, avec une exécution ultérieure lors de la récupération et de l’utilisation des données dans une requête de base de données de manière non sécurisée. Ces attaques sont particulièrement insidieuses car elles échappent à de nombreux contrôles de sécurité qui n’examinent que le traitement immédiat des entrées.

Pourquoi l’injection NoSQL peut être plus dangereuse

Parce que certaines bases NoSQL utilisent du code applicatif pour leurs requêtes, les attaquants peuvent non seulement effectuer des actions indésirables sur une base NoSQL, mais aussi exécuter du code malveillant et des entrées non validées dans l’application elle-même. Cette différence fondamentale rend l’injection NoSQL potentiellement plus grave que l’injection SQL traditionnelle.

Les attaques d’injection NoSQL ciblent les bases NoSQL qui utilisent des schémas dynamiques, ce qui peut les rendre plus vulnérables. La flexibilité qui rend les bases NoSQL attrayantes pour le développement crée également des surfaces d’attaque supplémentaires.

Les bases NoSQL peuvent être plus vulnérables aux violations de données en raison de contrôles de sécurité moins structurés et de leur nature distribuée, ce qui complique la configuration de la sécurité sur plusieurs nœuds et clusters.

Le paysage actuel des menaces

Les injections NoSQL sont relativement plus faciles à exploiter que les injections SQL classiques, mais les développeurs négligent souvent ces vulnérabilités, principalement par manque de sensibilisation. Cette combinaison de facilité d’exploitation et de méconnaissance fait de l’injection NoSQL une préoccupation critique pour les applications modernes.

Une collection complète de 400 commandes d’injection NoSQL a été documentée, répartie en 221 commandes malveillantes et 179 commandes bénignes, illustrant la variété et la sophistication des techniques d’attaque disponibles pour les acteurs malveillants.

L’injection NoSQL figure dans la catégorie Injection du Top 10 OWASP des Risques de Sécurité Applicative, soulignant son importance reconnue dans la communauté de la sécurité.

Stratégies de prévention complètes

Validation et nettoyage des entrées

Il est crucial de valider systématiquement les entrées utilisateur, de ne jamais faire confiance aux données provenant de l’utilisateur, et de toujours vérifier qu’elles correspondent aux attentes avant de les utiliser dans une requête. Ce principe de sécurité fondamental s’applique quel que soit la technologie de base de données utilisée.

Examinez chaque champ d’entrée et injectez systématiquement différents caractères de rupture de syntaxe pour identifier d’éventuels points d’injection lors des tests de sécurité. Les caractères de test courants incluent les guillemets simples, doubles, crochets, et les opérateurs spécifiques à la base.

Utiliser des requêtes paramétrées et des API sécurisées

Nous recommandons d’utiliser des requêtes préparées, qui séparent les données des commandes, empêchant toute tentative d’injection, et chaque paramètre doit être soigneusement vérifié pour s’assurer qu’il ne contient pas de caractères ou opérateurs dangereux.

L’approche privilégiée consiste à utiliser une API sécurisée qui évite l’interaction directe avec l’interpréteur, offre une interface paramétrée, ou transitionne vers des outils d’Object-Relational Mapping (ORM) pour réduire les risques d’injection.

Pour MongoDB en particulier, utilisez les fonctionnalités intégrées de construction de requêtes sécurisées qui n’exigent pas l’exécution de JavaScript. Évitez d’utiliser des opérateurs comme $where sauf si absolument nécessaire, et lorsque vous devez les utiliser, appliquez une validation rigoureuse des entrées.

Valider les types

Pour éviter les vulnérabilités d’injection NoSQL, les développeurs doivent valider les données utilisateur en identifiant les structures de données non souhaitées, comme les objets et tableaux, qui peuvent être utilisés pour injecter des modificateurs NoSQL. La vérification des types garantit que les entrées de type chaîne restent des chaînes et ne peuvent pas être transformées en opérateurs de requête.

Appliquer le principe du moindre privilège

Pour limiter les dégâts potentiels d’une injection NoSQL, les développeurs et administrateurs doivent considérer le type de droits d’accès accordés à une application, et la minimisation des privilèges du compte système d’exploitation sur lequel tourne la base de données est une bonne pratique.

Les comptes de base de données utilisés par les applications doivent avoir uniquement les permissions minimales nécessaires à leur fonctionnement. En cas de succès d’une injection, limiter les privilèges réduit les dégâts potentiels.

Mettre en place des listes blanches et noires

Il est important de définir des listes blanches pour les champs de données autorisés. Plutôt que d’essayer d’identifier toutes les entrées malveillantes (approche blacklist), spécifiez précisément à quoi ressemblent les entrées valides et rejetez tout le reste.

Maintenir les systèmes à jour

De nombreux produits NoSQL populaires sont en développement actif, il est donc essentiel d’utiliser la dernière version et de mettre à jour fréquemment, car des vulnérabilités sont découvertes quotidiennement. Les versions plus anciennes de bases NoSQL comme MongoDB comportaient de graves vulnérabilités de sécurité qui ont été corrigées dans les versions plus récentes.

Déployer des Web Application Firewalls

Déployez des pare-feux d’applications web (WAF) configurés pour détecter et bloquer les tentatives d’injection NoSQL. Les WAF modernes peuvent analyser les modèles de requêtes et identifier les structures suspectes avant qu’elles n’atteignent votre base.

Effectuer des tests de sécurité réguliers

Les chercheurs en sécurité peuvent utiliser des jeux de données pour analyser et comprendre les différentes vulnérabilités d’injection NoSQL, leurs motifs et vecteurs d’attaque potentiels, menant au développement de mesures de sécurité plus efficaces.

Menez des tests de pénétration réguliers spécifiquement axés sur les vulnérabilités d’injection NoSQL. Les outils d’analyse de sécurité automatisés doivent être complétés par des tests manuels réalisés par des professionnels de la sécurité connaissant les vecteurs d’attaque spécifiques à NoSQL.

Tests de vulnérabilités d’injection NoSQL

Techniques d’identification

Pour déterminer quels caractères sont interprétés comme syntaxe par l’application, vous pouvez injecter des caractères individuels ; par exemple, soumettre une apostrophe peut provoquer une erreur de syntaxe indiquant une vulnérabilité.

Lors des tests d’injection NoSQL, commencez par des techniques de fuzzing. Un exemple de chaîne de fuzz pour MongoDB est : '"{ ;$Foo} $Foo \xYZ`, et si cela provoque un changement par rapport à la réponse initiale, cela peut indiquer que l’entrée utilisateur n’est pas filtrée ou nettoyée correctement.

Tests booléens

Après avoir détecté une vulnérabilité, l’étape suivante consiste à déterminer si vous pouvez influencer des conditions booléennes en utilisant la syntaxe NoSQL en envoyant deux requêtes, une avec une condition fausse et une avec une condition vraie. Cette technique aide à confirmer la vulnérabilité et à en comprendre la portée.

Tests d’opérateurs

Pour tester si l’entrée du nom d’utilisateur traite l’opérateur de requête, vous pouvez essayer une injection utilisant l’opérateur $ne pour interroger tous les utilisateurs où le nom d’utilisateur n’est pas égal à une valeur invalide. Si l’application traite l’opérateur, vous avez confirmé une vulnérabilité.

La voie à suivre : développement axé sur la sécurité

La migration vers les bases NoSQL offre de véritables avantages en termes d’évolutivité, de flexibilité et de performance. Cependant, ces bénéfices s’accompagnent de responsabilités de sécurité qu’il ne faut pas négliger. L’idée que NoSQL équivaut à “Pas d’Injection” est non seulement fausse — elle est dangereuse.

Le manque de validation des entrées peut toujours causer des impacts graves pour les entreprises, quel que soit la technologie de base de données sous-jacente. À mesure que les bases NoSQL gagnent en popularité dans les applications web, mobiles et IoT, la surface d’attaque pour l’injection NoSQL s’élargit proportionnellement.

Les développeurs doivent aborder la sécurité NoSQL avec la même rigueur qu’ils appliquent aux bases SQL, en comprenant que des syntaxes différentes ne signifient pas des principes de sécurité différents. La règle fondamentale reste la même : ne faites jamais confiance à l’entrée utilisateur, validez et nettoyez toujours les données, et utilisez des pratiques de codage sécurisées adaptées à votre plateforme de base de données.

Conclusion

L’injection NoSQL représente un défi de sécurité critique dans le développement d’applications modernes. Bien que la syntaxe et les techniques diffèrent de l’injection SQL traditionnelle, la vulnérabilité sous-jacente — l’influence des requêtes par des entrées non nettoyées — demeure fondamentalement la même. La fausse croyance que les bases NoSQL sont intrinsèquement sécurisées contre les injections a créé un écart de connaissances dangereux que les attaquants exploitent activement.

Les organisations doivent reconnaître que s’éloigner de SQL ne signifie pas s’éloigner des vulnérabilités d’injection. En mettant en œuvre une validation complète des entrées, en utilisant des requêtes paramétrées, en appliquant le principe du moindre privilège et en maintenant à jour les correctifs de sécurité, les équipes de développement peuvent construire des applications NoSQL sécurisées qui tirent parti des avantages de ces bases modernes sans s’exposer à des attaques évitables.

La sécurité de nos applications ne dépend pas de la technologie de base de données que nous choisissons, mais des pratiques de sécurité que nous mettons en œuvre. L’injection NoSQL est évitable — mais seulement si nous reconnaissons la menace et prenons des mesures concrètes pour y faire face.