sql - 使用非 SQL 数据库是否消除了防范 "SQL injection"的需要？

Question

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

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

我是不是目光短浅？还是下一个伟大的数据库系统站稳脚跟只是时间问题，然后我会看到注入(inject)这些系统？

Answer 1

“注入(inject)”漏洞与文本上下文不匹配有关。每次将文本字符串放入另一个字符串上下文时，都需要进行编码以适应更改的上下文。盲目地将字符串塞在一起看起来很简单，但字符串处理的难度具有欺骗性。

具有纯粹基于对象接口(interface)的数据库不受注入(inject)漏洞的影响，就像 SQL 中的参数化查询一样。攻击者无法在他的字符串中放入任何内容来突破您放置他的字符串文字上下文。

但 GQL 具体不是其中之一。它是一种字符串查询语言，如果您将不受信任的未转义 Material 连接到像 "WHERE title='%s'" % title 这样的查询中，您就像使用完整的 SQL 一样容易受到攻击。也许 GQL 的有限功能使得利用它来完全破坏应用程序变得更加困难，但一般来说肯定不是不可能的，而且在最好的情况下，您的应用程序仍然是错误的，并且当人们尝试合法使用撇号时会崩溃。

GQL 有一个参数绑定(bind)接口(interface)。用它。抵制字符串黑客的诱惑。