Sécurité Nosql : Comprendre les risques, les attaques par injection NoSQL et les défenses

Nosql englobe un vaste ensemble de technologies de bases de données non relationnelles largement utilisées dans les applications modernes pour prendre en charge les schémas flexibles et l'évolutivité horizontale. Malgré leurs avantages, les systèmes NoSQL ne sont pas intrinsèquement sûrs de par leur conception. Faille d'injection NoSQLLes CVEs sont des éléments importants de la sécurité, de la façon dont les attaquants peuvent les exploiter et de la façon de s'en défendre systématiquement. Cet article propose une exploration technique approfondie pour les ingénieurs en sécurité, y compris des scénarios de menaces réelles, des stratégies préventives, des exemples de code et des références à des CVE à fort impact.

Qu'est-ce que NoSQL et pourquoi est-ce important pour la sécurité ?

Les bases de données NoSQL (abréviation de "Not Only SQL" ou "non-relational SQL") abandonnent les modèles relationnels traditionnels en faveur de modèles de données flexibles tels que les magasins de clés et de valeurs, les magasins de documents, les bases de données à base de colonnes et de graphes. Parmi les implémentations populaires, on peut citer MongoDB, CouchDB, Redis, Cassandreet Neo4j. Ces systèmes assurent l'évolutivité et la souplesse des schémas, mais ils introduisent également nouvelle sémantique des requêtes et pièges en matière de sécurité peu familiers aux ingénieurs habitués aux systèmes SQL. vaadata.com

Contrairement à SQL, chaque système NoSQL possède son propre langage de requête (par exemple, les requêtes basées sur JSON dans MongoDB) et une sémantique d'opérateur différente. Si cette diversité améliore la flexibilité, elle se traduit également par des problèmes d'accès à l'information. des vecteurs d'attaque uniques par injection parce que les entrées des utilisateurs sont souvent interpolées dans les requêtes de la base de données sans être correctement nettoyées. vaadata.com

Injection NoSQL : Qu'est-ce que c'est et quand cela se produit ?

À la base, une injection NoSQL se produit lorsqu'un attaquant envoie apport artisanal qui modifie la structure prévue d'une requête de base de données. Contrairement à la grammaire textuelle traditionnelle de l'injection SQL, l'injection NoSQL abuse souvent de la grammaire textuelle traditionnelle de l'injection SQL. Charges utiles JSON ou opérateurs de requête tels que $ne, $gt, $lt, $regexou $où pour manipuler la logique. vaadata.com

Exemples et scénarios concrets

Prenons un exemple typique d'authentification Node.js + MongoDB où les développeurs utilisent directement les données d'entrée du client pour demander des informations d'identification :

javascript

// Authentification vulnérable

db.users.find({

email : req.body.email,

mot de passe : req.body.password

});

Un attaquant pourrait fournir une valeur comme :

json

{"email" : { "$ne" : null }, "password" : { "$ne" : null } }

Cette requête renvoie les documents où l'email est pas null ET le mot de passe est pas null, ce qui permet de contourner l'authentification sans connaître les informations d'identification valides. vaadata.com

Bases de données NoSQL typiques et lieux d'injection

Type de base de données	Exemples	Risque lié à l'injection
Magasin de documents	MongoDB, CouchDB	Requêtes JSON et exécution JS
Clé-valeur	Redis, DynamoDB	L'évaluation de scripts moyens ou les opérations complexes nécessitent une utilisation prudente.
Famille de colonnes	Cassandra, HBase	Risque d'interpolation en cas de requête moyenne
Graphique	Neo4j	Les langages à forte interrogation comme Cypher peuvent être manipulés

Chaque modèle présente un profil de risque différent en raison des différences de langage des requêtes. Par exemple, MongoDB permet d'effectuer des requêtes à l'aide d'opérateurs tels que $où qui exécutent un JavaScript arbitraire, augmentant ainsi la surface d'attaque. InfoQ

Exemples de CVE à fort impact liés à l'injection NoSQL

Bien que les injections NoSQL aient tendance à être moins signalées que les injections SQL, les problèmes de sécurité documentés montrent qu'elles sont bien réelles. Par exemple :

• CVE-2024-48573: Une injection NoSQL dans Aquila CMS permettait à un attaquant de réinitialiser les mots de passe des comptes parce que les filtres fournis par l'utilisateur n'étaient pas assainis, permettant l'injection d'un opérateur malveillant. vaadata.com

D'autres bogues ont été signalés (par exemple, des problèmes de $où L'utilisation abusive des ODM) renforce le fait que les vecteurs d'injection peuvent provenir non seulement du code de l'application, mais aussi de l'ordinateur de l'utilisateur. Manipulation non sécurisée de la bibliothèque ou du schéma. Bright Security

Comment l'injection NoSQL peut être exploitée

L'impact des attaques par injection NoSQL varie en fonction de la base de données et du niveau de sécurité. Elles peuvent être utilisées pour

• Contourner la logique d'authentification
• Extraire des documents sensibles
• Modifier ou supprimer des données critiques
• Élever les privilèges
• Déclencher des vulnérabilités d'applications secondaires (par exemple, RCE via l'exécution de JavaScript)

Exemple : Contournement de l'authentification

javascript

// La charge utile de l'attaquant modifie la logique de la requête

db.users.find({

email : { $regex : ".*" },*

*password : { $regex : ".*" }

});

Cela correspond à toutes les informations d'identification parce que .* est une expression rationnelle qui correspond à tout, ce qui permet de contourner les contrôles de connexion. vaadata.com

Détection des injections NoSQL

Les tests d'injection NoSQL impliquent :

• Identifier les points où l'entrée de l'utilisateur est transmise directement dans les requêtes de la base de données
• Fuzzing des paramètres de l'utilisateur avec les touches de l'opérateur comme $ne, $gt, $lt
• Observation des changements de comportement de l'application (par exemple, contournement de l'authentification, différences dans les résultats des requêtes)
• Tests via des scanners automatisés et des techniques manuelles de pentesting Indusface

Les ingénieurs ont souvent recours à des sondes manuelles et à des outils automatisés pour simuler des charges utiles malveillantes.

Stratégies défensives : Validation des entrées et renforcement des requêtes

L'essentiel de la défense contre les injections NoSQL consiste à traiter les éléments suivants toutes les entrées de l'utilisateur sont considérées comme non fiables et en éliminant toute possibilité pour cette entrée de modifier la structure de la requête.

Meilleures pratiques

1. Validation des entrées et liste blanche N'autoriser que les champs et les types de données attendus. Rejeter ou assainir les caractères spéciaux et les opérateurs JSON susceptibles d'altérer la logique de la requête. Indusface
2. Requêtes paramétrées/préparées Bien que NoSQL ne dispose pas d'instructions préparées universelles, de nombreux pilotes prennent en charge des constructeurs de requêtes plus sûrs qui évitent la concaténation de chaînes.
3. Validation du schéma Utiliser des schémas de documents ou la validation de modèles (par exemple, les schémas Mongoose) pour faire respecter les formes d'entrée attendues.
4. Désactivation des opérateurs dangereux Désactiver l'évaluation des $où, $evalou l'exécution de JavaScript dans les configurations de base de données. Indusface
5. Politiques de moindre privilège Restreindre les autorisations des utilisateurs de la base de données afin que, même en cas d'injection, le rayon d'action des opérations (lecture/écriture) soit limité.
6. Journalisation et surveillance Enregistrer les modèles de requête inhabituels pour détecter les tentatives d'injection et déclencher des alertes.

Exemples de code : Modèles d'attaque et de défense

Vous trouverez ci-dessous des extraits de code pratiques illustrant à la fois l'exploitation et l'atténuation des risques.

Attaque de contournement de l'authentification de MongoDB

javascript

// Non sûr : entrée directe de l'utilisateur dans la requête

db.users.find({

username : req.body.user,

mot de passe : req.body.pass

});

Modèle défensif : Liste blanche et intrants Cast

javascript

const userInput = {

user : String(req.body.user || ""),

pass : String(req.body.pass || "")

};

db.users.find({ username : userInput.user, password : userInput.pass }) ;

Abus de regex dans les requêtes

Charge utile de l'attaque :

json

{"name" : { "$regex" : ".*" } }

Défense (Regex de désaveu) :

javascript

if (!/^[A-Za-z0-9_]+$/.test(req.body.name)) {

lancer une nouvelle erreur ("Caractères non valides") ;

}

Empêcher l'exécution de JavaScript dans MongoDB

Peu sûr :

javascript

db.users.find({ $where : "this.age > 25" }) ;

Configuration sûre :

bash

# mongod.conf

setParameter :

javascriptEnabled : false

Simulation de requête paramétrée

Peu sûr :

javascript

collection.find({ filter : JSON.parse(req.body.filter) }) ;

Parsing sûr avec la bibliothèque de désinfection

javascript

const sanitize = require('mongo-sanitize') ;

const filter = sanitize(req.body.filter) ;

collection.find(filter) ;

Filtrage des entrées de l'API REST

Vulnérable :

javascript

app.post("/search", (req, res) =>

db.collection("items").find(req.body).toArray()

);

Trempé :

javascript

const allowedFields = ["catégorie", "prix"] ;

const query = {} ;

allowedFields.forEach(f => {

if (req.body[f]) query[f] = req.body[f] ;

});

db.collection("items").find(query).toArray() ;

Tests de sécurité négligents et automatisés pour les serveurs NoSQL

Dans les applications complexes, l'identification manuelle de chaque vecteur d'injection à travers les API, les entrées dynamiques et les microservices est souvent intenable. Penligent, une plateforme de tests de pénétration pilotée par l'IA, aide les équipes de sécurité en :

• Générer et injecter automatiquement des charges utiles NoSQL élaborées afin de rechercher des vulnérabilités.
• Corrélation entre les requêtes et les comportements à risque
• Intégration avec les pipelines CI/CD pour détecter rapidement les régressions
• Produire des rapports prioritaires alignés sur les classifications OWASP et CWE

Cette approche complète le SAST/DAST traditionnel avec analyse contextuelleLes règles statiques sont particulièrement utiles pour les langages d'interrogation dynamiques NoSQL, pour lesquels les règles statiques seules peuvent être insuffisantes.

Conclusion : NoSQL n'est pas immunisé - Concevoir de manière sécurisée

Les bases de données NoSQL offrent évolutivité et flexibilité, mais elles ne sont pas à l'abri des risques d'injection simplement parce qu'elles utilisent une syntaxe différente. Les failles d'injection dans les bases de données NoSQL peuvent contourner l'authentification, exposer les données ou permettre des opérations non autorisées lorsque les données sont traitées de manière incorrecte. En combinant une forte validation des entrées, l'application des schémas, l'utilisation de pilotes sécurisés et des tests automatisés (y compris des plateformes assistées par l'IA comme Penligent), les ingénieurs peuvent réduire de manière significative l'exposition aux attaques par injection nosql.