是否使用非SQL数据库，避免对防范“SQL注入”的需要？

Question

这可能看起来像一个明显的（或不那么明显）的问题，但让我解释。我编码了使用谷歌的数据库技术，BigTable的谷歌的App Engine的网站。任何App Engine的程序员都知道，谷歌有一个名为GQL自己的有限的查询语言。其结果是，我很想不要做的SQL（或GQL）注入我的应用程序的任何检查，因为我认为谷歌没有使用它的后端方法原始字符串查询来获取数据。

此外，对于DB技术如CouchDB的，MongoDB的，和其它的对象或文档库（又名的NoSQL）数据库似乎是避免需要检查如果恶意用户在注射数据库操作的命令。他们往往有直接在数据库中的对象映射在您所选择的语言对象库。我知道有一些这样做还有许多SQL库，但我认为在一定程度上，他们正在整合参数跑过来一个字符串查询，正是如此我仍然必须使用SQL注入的保护，即使这些框架。

我被短视？或者它只是一个直到下一个伟大的DB系统扎根，然后我会看看注入到这些系统？时间问题

Answer 1

“注射”的孔是具有文本上下文错配做。你把一个文本字符串转换为字符串的另一个上下文每次你需要做的编码，以适应改变的环境。这似乎诱人简单盲目东西串在一起，但字符串处理的难度是靠不住的。

具有纯基于对象的接口数据库是免疫注射漏洞，就像参数化查询是在SQL。没有什么攻击者可以把他的弦乐打出来的字符串字面背景中，你已经把他的。

但是GQL特别是不其中之一。这是一个字符串的查询语言，如果你去串联不可信转义材料到像"WHERE title='%s'" % title查询时，你就像你跟全对SQL脆弱。也许GQL的能力有限，使其更加难以利用，要完全破坏应用程序，但肯定不是一般不可能的，在最好的情况下，你的应用程序仍然是错误的，并会翻倒，当人们试图合理地使用撇号。

GQL具有参数结合界面。用它。抗蚀串黑客的诱惑力。

Answer 2

SQL-亚像GQL显然还是关注自己与它 - 但像CouchDB的，伏地魔等纯非SQL数据库应该把与获取数据，而不用SQL注入式攻击的关注

这不过不会做内容验证原谅你，因为虽然它可能不会打破数据库，它可能会破坏你的应用程序，并允许之类XSS（如果它是一个Web应用程序）。

Answer 3

这是从或通过用户输入操作时间不限数据被用于控制的代码的执行，需要有消毒。我已经看到其中的代码中使用的用户输入而无需消毒输入执行命令的情况。它没有被攻击，但是如果那是它本来是一个可怕的攻击向量。

Answer 4

SQL注入是仅一种类型的安全漏洞，其中任何不受控制的输入获取评估的子集。

techincally，你可以 “注入” 的JavaScript等等。