我在阅读我值得信赖的 O'Reilly 书籍时偶然发现了一段关于 Mongo 如何从本质上避免类似 SQL 注入缺陷的泥潭。
在我的直觉中，我想我明白这一点。如果将未经处理的 var 传递到查询中，它们将无法通过 UNION、JOIN、查询转注释等突破面向文档的查询结构。
MongoDB 如何避免 SQL 注入混乱？仅仅是这种查询语法的本质吗？
【问题讨论】：
body-parser 与 nodejs express lib）。如果您将 post 参数解析为 JSON（这很常见），然后将这些参数（或这些参数的属性）直接传递到 mongo 查询中，那么攻击者可以在您期望字符串/数字的位置插入一个 js 对象（例如他们可以通过{$gt:-1} 并查看您收藏中的所有文档）
标签： sql mongodb sql-injection
总结一下MongoDBdocumentation
BSON
当客户端程序在 MongoDB 中组装查询时，它会构建一个 BSON 对象，而不是字符串。因此传统的 SQL 注入攻击是 没问题。
但是，MongoDB 也不能免受注入攻击。如同一文档中所述，注入攻击仍然可能，因为 MongoDB 操作允许直接在服务器上执行任意 JavaScript 表达式。文档对此进行了详细介绍：
【讨论】：
MongoDB 通过不解析来避免潜在的问题。
任何涉及将用户数据编码为可解析的格式化文本的 API，都可能导致调用方和被调用方在如何解析该文本方面存在分歧。当数据被误解为元数据时，这些分歧可能是安全问题。无论您是在谈论 printf 格式字符串（包括 HTML 中用户生成的内容）还是生成 SQL，这都是正确的。
由于 MongoDB 不解析结构化文本来确定要做什么，因此不可能将用户输入误解为指令，因此不会存在安全漏洞。
顺便提一下，避免使用需要解析的 API 的建议是 http://cr.yp.to/qmail/guarantee.html 中的第 5 项。如果您对编写安全软件感兴趣，那么其他 6 条建议也值得一看。
更新（2018 年）：据我所知，我给出的原始答案仍然正确。从发给 MongoDB 的内容到发回的内容，没有 SQL 注入攻击。我知道的注入攻击发生在 MongoDB 之外，实际上是外部语言和库如何设置将传递给 MongoDB 的数据结构的问题。此外，漏洞的位置在于数据在成为数据结构的过程中如何被解析。因此，最初的答案准确地描述了如何避免注入攻击，以及使您面临风险的原因。
但这种准确性对于因自己的代码中不明显的缺陷而受到注入攻击的程序员来说是一种冷酷的安慰。我们中很少有人区分外部工具以及我们的代码与该外部工具之间的所有层。事实仍然是，我们需要保持警惕才能预测和关闭注入攻击。使用所有工具。在可预见的未来，情况仍将如此。
【讨论】：
【讨论】：
数据库可能无法解析内容，但代码的其他区域存在漏洞。
【讨论】：
为了防止 SQL 注入，客户端可以使用 MongoDB 的语言 API。这样，所有的输入都是简单的值——不能注入命令。 Java 示例：
collection.find(Filters.eq("key", "input value"))
缺点是您无法轻松测试您的过滤器。您不能将其复制到 Mongo 的 shell 并对其进行测试。对于更大、更复杂的过滤器/查询尤其成问题。
但是！！！还有一个 API 不使用过滤器的 API - 可以解析任何 json 过滤器。 Java 示例如下：
collection.find(BasicDBObject.parse("{key: "input value"}"));
这很好，因为您可以将过滤器直接复制到 MongoDB shell 中进行测试。
但是！！！ （最后但是，我保证）这很容易发生 NoSql 注入。 Java 示例，其中输入值为{$gt: ""}。
collection.find(BasicDBObject.parse("{key: {$gt: ""}}"));
在最后一个示例中，所有内容都被返回，尽管我们的意思是只返回特定的记录。
直接使用过滤器时，请参阅here 对 SQL 注入的更详尽说明。
最后一件事。我认为有一种方法可以同时使用原始过滤器并且仍然可以防止 SQL 注入。例如，在 Java 中，我们可以使用Jongo's parameterized queries。
【讨论】：