我在阅读我值得信赖的 O'Reilly 书籍时，偶然发现了一段关于 Mongo 如何从本质上避免类似 SQL 注入(inject)缺陷的泥潭。
在我的直觉中，我想我明白这一点。如果未过滤的 var 被传递到查询中，它们就无法通过 UNION、JOIN、查询转注释等突破面向文档的查询结构。
MongoDB 如何避免 SQL 注入(inject)困惑？仅仅是这种查询语法的本质吗？
最佳答案
MongoDB 通过不解析来避免潜在的问题。
任何涉及将用户数据编码为可解析的格式化文本的任何 API 都有可能导致调用方和被调用方在如何解析该文本方面存在分歧。当数据被误解为元数据时，这些分歧可能是安全问题。无论您是在谈论 printf 格式字符串，包括用户在 HTML 中生成的内容，还是生成 SQL，这都是正确的。
由于 MongoDB 不解析结构化文本来确定要做什么，因此不可能将用户输入误解为指令，因此也不存在安全漏洞。
顺便提一下，避免使用需要解析的 API 的建议是 http://cr.yp.to/qmail/guarantee.html 中的第 5 项。 .如果您对编写安全软件感兴趣，那么其他 6 条建议也值得一看。
更新(2018 年):据我所知，我给出的原始答案仍然正确。从发给 MongoDB 的内容到发回的内容，没有 SQL 注入(inject)攻击。我知道的注入(inject)攻击发生在 MongoDB 之外，实际上是外部语言和库如何设置将传递给 MongoDB 的数据结构的问题。此外，漏洞的位置在于数据在成为数据结构的过程中如何被解析。因此，原始答案准确地描述了如何避免注入(inject)攻击，以及使您面临风险的原因。
但是，这种准确性对于因自己代码中不明显的缺陷而受到注入(inject)攻击的程序员来说是一种冷酷的安慰。我们中很少有人区分外部工具以及我们的代码与该外部工具之间的所有层。事实仍然是，我们需要保持警惕才能预测和关闭注入(inject)攻击。使用所有工具。在可预见的 future ，情况仍将如此。
关于sql - MongoDB如何避免SQL注入(inject)困惑？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5021456/