Comment MongoDB évite-t-il le désordre d’injection SQL?

Je lisais mon fidèle livre O’Reilly et je suis tombé sur un passage sur la manière dont Mongo, par nature, évite le bourbier des failles SQL.

Dans mes sortingpes, je pense que je comprends cela. Si des vars non homologués sont passés dans des requêtes, ils ne peuvent pas sortir de la structure de requête orientée document avec un UNION , JOIN , une requête tournée en commentaire, etc.

Comment MongoDB évite-t-il le désordre d’injection SQL? Est-ce juste par nature de cette syntaxe de requête?

MongoDB évite le risque de problèmes en n’analysant pas.

N’importe quelle API, où que ce soit, qui implique le codage de données utilisateur dans un texte formaté qui est analysé, peut entraîner un désaccord entre l’appelant et l’appelé sur la manière dont ce texte doit être analysé. Ces désaccords peuvent être des problèmes de sécurité lorsque les données sont interprétées comme des métadonnées. Cela est vrai que vous parliez de chaînes au format printf, y compris du contenu généré par l’utilisateur en HTML ou de la génération de code SQL.

Puisque MongoDB n’parsing pas le texte structuré pour déterminer ce qu’il faut faire, il n’y a aucune possibilité de mal interpréter les entrées de l’utilisateur en tant qu’instructions, et donc pas de trou de sécurité possible.

Incidemment, le conseil d’éviter les API nécessitant une parsing est le point 5 de http://cr.yp.to/qmail/guarantee.html . Si vous souhaitez écrire un logiciel sécurisé, les 6 autres suggestions méritent également d’être examinées.

Pour résumer la documentation MongoDB

BSON

Lorsqu’un programme client assemble une requête dans MongoDB, il crée un object BSON, pas une chaîne. Les attaques par injection SQL traditionnelles ne sont donc pas un problème.

Cependant, MongoDB n’est pas à l’abri des attaques par injection . Comme indiqué dans la même documentation, les attaques par injection sont toujours possibles car les opérations MongoDB permettent d’exécuter des expressions JavaScript arbitraires directement sur le serveur. La documentation va dans ce détail:

http://docs.mongodb.org/manual/faq/developers/#javascript

La firebase database peut ne pas parsingr le contenu, mais d’autres zones du code sont vulnérables.

https://www.owasp.org/index.php/Testing_for_NoSQL_injection

Pour se protéger contre l’injection SQL, les clients peuvent utiliser les API de langue de MongoDB. De cette façon, toutes les entrées sont simples – les commandes ne peuvent pas être injectées. Un exemple Java:

collection.find(Filters.eq("key", "input value"))

L’inconvénient est que vous ne pouvez pas tester facilement votre filtre. Vous ne pouvez pas le copier sur le shell de Mongo et le tester. Particulièrement problématique avec des filtres / requêtes plus gros et plus complexes.

MAIS!!! il y a aussi une API pour ne pas utiliser l’API du filtre – ce qui permet d’parsingr n’importe quel filtre json. Exemple Java ci-dessous:

 collection.find(BasicDBObject.parse("{key: "input value"}")); 

C’est bien parce que vous pouvez copier le filtre directement sur le shell MongoDB pour le tester.

MAIS!!! (dernier mais, promis) ceci est sujet à une injection NoSql. Exemple Java, où la valeur d’entrée est {$gt: ""} .

 collection.find(BasicDBObject.parse("{key: {$gt: ""}}")); 

Dans ce dernier exemple, tout est retourné, même si nous voulions seulement renvoyer les enregistrements spécifiques.

Voir ici une explication plus approfondie de l’injection SQL lors de l’utilisation directe des filtres.

Une dernière chose. Je pense qu’il existe un moyen d’utiliser les deux filtres bruts tout en protégeant contre l’injection SQL. Par exemple, en Java, nous pouvons utiliser les requêtes paramétrées de Jongo .