使用非SQL数据库是否消除了防范“SQL注入”的需要？

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

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

---

我是不是近视了？或者说，下一个强大的DB系统成立只是时间问题，然后我将看到注入到这些系统中？

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

---

但是，这并不能免除您进行内容验证的责任，因为虽然它可能不会破坏数据库，但它可能会破坏您的应用程序，如果它是一个web应用程序，它可能会允许XSS之类的操作。

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

< P> SQL注入只是一个安全缺陷类型的子集，其中任何未控制的输入得到评估。

---

从技术上讲，您可以注入javascript等。注入漏洞与文本上下文不匹配有关。每次将文本字符串放入字符串的另一个上下文时，都需要进行编码以适应更改的上下文。盲目地将字符串组合在一起似乎很简单，但字符串处理的困难是具有欺骗性的

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

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

---

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

JavaScript注入是XSS或跨站点脚本。@Justice，注入JS不必跨站点，您可以在本地通过输入feild来完成。@Justice，我考虑过XSS，但不是故意提到的，因为这是一整罐蠕虫：如果我错了，请纠正我，但GQL只允许选择查询，所以假设您从“选择”开始。。。从“种类”中，除了选择可能您不想看到的相同实体种类的行之外，您无法向其追加任何内容来修改数据。如果允许用户查看特定类型的所有行，那么就不可能发生注入攻击。当然，但是SELECT在坏人手中可能非常危险。典型的例子是，用户名=“…”和密码=“…”被扩展到username='admin'或username='x'和password='x'的位置，以便在不使用密码的情况下登录到管理员帐户，但根据应用程序逻辑，存在许多潜在漏洞。