使用非SQL数据库是否避免了防止"SQL注入"的需要？

这似乎是一个明显(或不那么明显)的问题,但让我解释一下.我正在使用Google的数据库技术BigTable编写Google App Engine网站.任何App Engine程序员都会知道Google有自己的有限查询语言GQL.因此,我很想不在我的应用程序中检查SQL(或GQL)注入,因为我假设Google没有在其后端方法上使用原始字符串查询来获取数据.

此外,用于数据库技术的库(如CouchDB,MongoDB和其他对象或文档(也称为NoSQL)数据库)似乎无需检查恶意用户是否正在注入数据库操作命令.它们通常具有直接将数据库中的对象映射到您选择的语言对象的库.我知道有很多SQL库也可以这样做,但我认为在某种程度上它们组合参数来对字符串运行查询,因此即使使用这些框架,我仍然必须使用SQL注入保护.

我是短视的吗？或者只是时间问题,直到下一个伟大的数据库系统抓住,然后我会看到注入这些系统？

"注入"漏洞与文本上下文不匹配有关.每次将文本字符串放入另一个字符串上下文时,都需要进行编码以适应更改的上下文.盲目地将字符串拼凑在一起看起来很诱人,但字符串处理的难度很大.

具有纯粹基于对象的接口的数据库不受注入漏洞的影响,就像参数化查询在SQL中一样.攻击者没有任何东西可以放入他的字符串中以打破你放置他的字符串字面上下文.

但GQL并不是其中之一.它是一种字符串查询语言,如果你将不受信任的非转义材料连接成一个类似的查询"WHERE title='%s'" % title,你就像使用全文SQL一样容易受到攻击.也许GQL的有限功能使得利用它来完全破坏应用程序变得更加困难,但总的来说肯定不是不可能的,并且在最好的情况下,你的应用程序仍然是错误的,当人们试图合法地使用撇号时,它将会失败.

GQL有一个参数绑定接口.用它.抵制字符串黑客攻击的诱惑力.