我读了一本关于Reimongly和trusty的书.
凭直觉,我想我明白这一点.如果未初始化的VAR被传递到查询中,它们就无法用UNION
、JOIN
、由查询转换的注释等打破面向文档的查询 struct .
MongoDB如何避免SQL注入混乱?这仅仅是因为这种查询语法的性质吗?
我读了一本关于Reimongly和trusty的书.
凭直觉,我想我明白这一点.如果未初始化的VAR被传递到查询中,它们就无法用UNION
、JOIN
、由查询转换的注释等打破面向文档的查询 struct .
MongoDB如何避免SQL注入混乱?这仅仅是因为这种查询语法的性质吗?
MongoDB通过不解析避免了潜在的问题.
任何涉及将用户数据编码为被解析的格式化文本的API,无论在何处,都有可能导致调用者和被调用者在该文本的解析方式上产生分歧.当数据被误解为元数据时,这些分歧可能是安全问题.无论您谈论的是printf格式的字符串,包括HTML中用户生成的内容,还是生成SQL,都是如此.
由于MongoDB不会解析 struct 化文本以确定要做什么,因此不可能将用户输入误解为指令,因此不存在可能的安全漏洞.
顺便提一下,避免使用需要解析的API的建议是http://cr.yp.to/qmail/guarantee.html中的第5项.如果你对编写安全软件感兴趣,其他6条建议也值得一看.
更新(2018):据我所知,我给出的原始答案仍然是真实的.从发送给MongoDB的内容到发送回的内容,不存在SQL注入攻击.据我所知,注入攻击发生在MongoDB之外,实际上是外部语言和库如何设置将传递给MongoDB的数据 struct 的问题.此外,漏洞的位置在于如何在数据成为数据 struct 的过程中解析数据.因此,最初的答案准确地描述了如何避免注射攻击,以及什么会让你面临注射攻击的风险.
但对于一个程序员来说,这种精确性是一种冷淡的安慰,他受到了注入攻击,这些攻击来自于他们自己的代码中不明显的缺陷.我们中很少有人区分外部工具和代码与外部工具之间的所有层.事实仍然是,我们需要保持警惕,以预测和阻止注射攻击.用各种工具.在可预见的future ,情况依然如此.