Injection NoSQL

Qu’est-ce que l’injection NoSQL ?

L’injection NoSQL est une vulnérabilité qui permet à un pirate malveillant d’introduire (d’injecter) du code indésirable dans les requêtes de base de données exécutées par les bases de données NoSQL.

Gravité:		très sévère
Prévalence:		découvert rarement
Portée:		peut apparaître dans les bases de données NoSQL
Impact technique :		accès à la base de données
Conséquences dans le pire des cas :		contrôle total sur l’application
Solution rapide:		entièrement dépendant du type de base de données NoSQL

Qu’est-ce que NoSQL ?

Le terme NoSQL ( non-SQL ou pas seulement SQL ) est utilisé pour décrire les bases de données non relationnelles en général et peut faire référence à de nombreux types de bases de données et de modèles de données, y compris clé-valeur, clé-document, colonne-famille et graphique bases de données. Les bases de données NoSQL ont rapidement gagné en popularité ces dernières années, avec des produits grand public tels que MongoDB, Apache Cassandra, Apache HBase, Apache CouchDB, Neo4j, RavenDB, Redis, OrientDB, DynamoDB, HyperTable, Google Cloud Datastore et bien d’autres.

Les moteurs de base de données NoSQL utilisent des structures de données différentes de celles des bases de données relationnelles et, bien qu’ils ne prennent généralement pas en charge les instructions SQL ou les requêtes SQL, ils offrent tous aux utilisateurs des moyens d’exécuter des requêtes. Contrairement aux bases de données SQL, il n’y a pas de langage ou de syntaxe de requête commun, de sorte que le format de requête dépend du produit de base de données spécifique et des détails de mise en œuvre de l’application Web ou de l’API. Cela signifie que vos requêtes varieront en fonction non seulement de la base de données, mais également du langage de programmation (par exemple, Python, PHP, Node.js, etc.) et du framework (par exemple, Spring). Même ainsi, la plupart des requêtes NoSQL sont basées sur JSON, et elles incluront souvent une entrée utilisateur. Cela signifie que, comme toujours avec les entrées utilisateur non nettoyées, les bases de données NoSQL peuvent également être vulnérables aux attaques par injection.

Comment fonctionne l’injection NoSQL ?

Les injections NoSQL ne reposent pas sur un langage de requête commun, de sorte qu’une vulnérabilité d’injection donnée n’affecte qu’un seul type de base de données NoSQL spécifique. En dehors de cela, les attaques par injection NoSQL sont similaires aux attaques par injection SQL traditionnelles – l’attaquant fournit une charge utile malveillante dans l’entrée de l’utilisateur, comme les formulaires ou les requêtes HTTP, et si cette entrée est livrée à la base de données NoSQL sans nettoyage, cela peut entraîner la base de données pour exécuter les commandes fournies par l’attaquant.

Exemples d’injection NoSQL

Pour comprendre comment une requête NoSQL est construite et où elle peut être vulnérable à une attaque par injection, nous nous concentrerons sur MongoDB en tant que base de données NoSQL la plus populaire, en y accédant à l’aide de PHP. Voici un exemple simple qui accède à une base de données MongoDB pour effectuer une authentification :

$username = $_POST['username'];
$password = $_POST['password'];
$connection = new MongoDB\Client('mongodb://localhost:27017');
if($connection) {
	$db = $connection->test;
	$users = $db->users;
	$query = array(
		"user" => $username,
		"password" => $password
	);
	$req = $users->findOne($query);
}

Comme vous pouvez le voir, les paramètres de nom d’utilisateur et de mot de passe utilisés pour l’authentification sont extraits d’une requête POST puis directement insérés dans la requête. Semblable à d’autres types d’injection, cela permet à un utilisateur malveillant d’entrer une charge utile d’injection NoSQL qui fournit un accès non authentifié.

Pour réussir une injection MongoDB, il peut suffire de fournir les données d’entrée malveillantes suivantes dans une requête POST :

nom d'utilisateur[$eq]=admin&mot de passe[$ne]=foo

L’ opérateur de requête [$ne] signifie pas égal , donc la requête résultante trouvera le premier enregistrement où le nom d’utilisateur est admin et le mot de passe n’est pas foo . Si un tel code est utilisé pour l’authentification et que l’ utilisateur admin existe, l’attaquant sera connecté en tant que cet utilisateur.

D’autres opérateurs MongoDB peuvent être abusés de la même manière, par exemple, [$lt] et [$gt] ainsi que [$ regex ] . En utilisant des expressions régulières dans le scénario ci-dessus, les attaquants pourraient même être en mesure d’énumérer tous les utilisateurs en essayant diverses combinaisons dans l’ordre et en évaluant les résultats.

Attaques avancées et injections JavaScript

Les requêtes MongoDB incluent généralement l’ opérateur $where , qui introduit des possibilités d’attaques NoSQL sérieuses incluant des objets JavaScript. Par exemple, un développeur peut vouloir utiliser l’ opérateur $where de la manière suivante pour accéder à un enregistrement pour un utilisateur particulier :

$query = array('$where' => 'this.name === \''.$name.'\'');

Dans ce cas, un attaquant pourrait utiliser l’astuce suivante de comparaison de chaînes vides en injectant dans $name :

'; return '' == '

En conséquence, la requête deviendra :

"$where": "this.name === ''; return '' == ''"

Comme le résultat est toujours vrai, l’attaquant recevra la liste complète des utilisateurs.

L’opérateur $where est en fait évalué comme du code JavaScript, de sorte que l’attaquant pourrait également passer un paramètre avec une chaîne malveillante qui inclut du JavaScript arbitraire, par exemple :

'; tandis que(vrai){}'

Cet exemple crée une boucle sans fin qui aboutit à une attaque par déni de service.

Conséquences potentielles d’une attaque par injection NoSQL

Les conséquences des attaques par injection NoSQL dépendent du type de base de données et de la manière dont la communication de la base de données est implémentée. L’attaquant peut contourner l’authentification, extraire des données, modifier des données ou même obtenir un contrôle total sur l’application Web. En conséquence, ils peuvent même être en mesure d’accéder au système d’exploitation sous-jacent et de prendre le contrôle du serveur Web.

Comment détecter les vulnérabilités d’injection NoSQL ?

La meilleure façon de détecter les vulnérabilités d’injection NoSQL varie selon qu’elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, il peut suffire d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est sensible aux injections NoSQL, vous pouvez supposer que votre logiciel est vulnérable. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’une solution d’analyse de la composition logicielle (SCA) .
• Si vous développez votre propre logiciel ou souhaitez avoir la possibilité de trouver des vulnérabilités d’injection NoSQL jusqu’alors inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité d’injection NoSQL pour être certain qu’elle existe. Cela nécessite soit d’effectuer un pentesting manuel avec l’aide de chercheurs en sécurité, soit d’utiliser un outil de sécurité d’application Web qui peut utiliser l’automatisation pour exploiter les vulnérabilités Web. 

Comment prévenir les vulnérabilités d’injection NoSQL

Pour empêcher les injections NoSQL, vous devez suivre les meilleures pratiques générales de cybersécurité et toujours traiter les entrées utilisateur comme non fiables. Voici quelques conseils généraux de validation des entrées utilisateur pour toutes les bases de données NoSQL :

• Utilisez une bibliothèque de désinfection appropriée, telle que mongo-sanitize ou mongoose pour MongoDB.
• Si vous ne trouvez pas de bibliothèque pour votre environnement, convertissez l’entrée utilisateur en type attendu. Par exemple, convertissez les noms d’utilisateur et les mots de passe en chaînes.
• Dans le cas de MongoDB, ne combinez jamais directement les opérateurs where , mapReduce ou group avec l’entrée de l’utilisateur car ils pourraient permettre aux attaquants d’injecter du JavaScript, ce qui les rendrait particulièrement dangereux. Pour plus de sécurité, définissez javascriptEnabled sur false dans mongod.conf chaque fois que possible.

Comment atténuer les attaques par injection NoSQL ?

Contrairement à de nombreuses autres vulnérabilités Web, les injections NoSQL peuvent être causées non seulement par un code d’application Web non sécurisé, mais également par des vulnérabilités dans les bases de données NoSQL elles-mêmes. Pour améliorer l’atténuation, vous devez toujours utiliser les dernières versions des bases de données NoSQL, d’autant plus que certains produits, dont MongoDB, étaient connus par le passé pour présenter de graves vulnérabilités.

Notez que puisque les bases de données NoSQL sont une technologie beaucoup plus récente par rapport aux bases de données SQL et qu’il existe également de nombreux types différents, le risque d’erreur du développeur est beaucoup plus élevé. Pour minimiser les risques, assurez-vous de toujours suivre le principe du moindre privilège en exécutant votre application avec les privilèges les plus bas possibles. De cette façon, même une attaque réussie ne donnera pas accès à d’autres ressources côté serveur.