在防止SQL注入时，PG:：Connection#exec_参数是否与使用准备好的语句相同？

准备好的语句可以很好地防止SQL注入，并且使用手动将变量注入SQL查询是邪恶的，应该永远不要这样做

但是呢？它提供的sql注入保护级别是否与准备好的语句相同

如果它确实提供了针对sql注入的保护，那么它总是正确的，还是只有在显式绑定参数时才正确；博士：是的

我不知道Ruby驱动程序的内部细节。我假设它可以使用三种策略。从理论上讲，只有一种可能受到顶级SQL注入攻击（下文将对此进行详细介绍），但所有类型的攻击都可能受到较低级别SQL注入攻击的攻击，就像准备好的语句一样

要理解这一点，您需要了解PostgreSQL如何执行查询：

查询被解析为解析树

参数用于计划查询

计划执行了

提供数据以供返回

在准备好的报表中，计划会被保存，但这并不是使它们安全的原因。对于顶级攻击，使它们更安全的是参数与要解析的查询分开发送

第一种策略可以是服务器端准备的语句。在这种情况下，计划将被保存并可能被重用，这可能会对性能产生不良（或可取）影响

第二个是，PostgreSQL协议允许单独发送查询和参数，即使不使用准备好的语句。这具有相同的安全优势，但不允许计划重用。看看代码，这似乎是该方法的首选工作方式

第三，您可以进行客户端转义。这仍然比您自己做的任何事情都要安全，因为它可能位于中心位置等等。我知道Perl的DBD:：Pg可以回到这一点上，但几乎从来没有这样做过。我没有看到退路，但也许有一条我错过了

因此，一般来说，我会说是的，即使使用最差的方法，这确实提供了可比的好处

注意，我一直在谈论顶级攻击。如果您在某个地方（例如从触发器）调用一个函数，您也可以在那里进行SQL注入，这是可能的。这种情况发生在涉及动态SQL但通常不是问题的地方。上述任何方法都无法避免这种情况，因为计划阶段将作为上述执行阶段的一个子部分出现，并且参数始终已填写

这就是为什么应用程序所有级别的良好编码实践都很重要的原因