4

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

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

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

4

4 回答 4

7

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

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

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

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

于 2009-12-01T02:11:43.767 回答
2

像 GQL 这样的 SQL 子集显然仍然关心它——但是像 CouchDB、Voldemort 等纯非 SQL 数据库应该放置和获取数据，而不用担心 SQL 注入式攻击。

然而，这并不能成为您进行内容验证的借口，因为虽然它可能不会破坏数据库，但它可能会破坏您的应用程序并允许 XSS 之类的事情（如果它是一个 Web 应用程序）。

于 2009-12-01T01:53:15.083 回答
1

任何时候使用来自用户输入或由用户输入操作的数据来控制代码的执行，都需要进行清理。我见过代码使用用户输入来执行命令而不清理输入的情况。它没有被利用，但如果被利用，那将是一个可怕的攻击媒介。

于 2009-12-01T01:58:30.593 回答
1

SQl 注入只是一种安全漏洞的子集，其中任何不受控制的输入都会被评估。

从技术上讲，您可以“注入” javascript 等。

于 2009-12-01T01:58:38.083 回答