sql - 在防止 SQL 注入(inject)时，PG::Connection#exec_params 是否与使用准备好的语句相同？

Question

是admitted准备好的语句可以很好地防止 SQL 注入(inject)，并且使用 PG::Connection#exec 将变量手动注入(inject)到 sql 查询中是邪恶的，不应该永远做。

但是PG::Connection#exec_params呢？ ？它是否提供与准备好的语句相同级别的 sql 注入(inject)保护？

如果它确实提供了针对 sql 注入(inject)的保护，它是始终为真还是仅当您显式绑定(bind)参数时为真？

Answer 1

TL;DR 是的。

我不知道 Ruby 驱动程序的内部细节。我假设它可以使用三种策略。理论上只有一个可能会受到顶级 SQL 注入(inject)攻击(下面会详细介绍)，但所有都可能容易受到较低级别的 SQL 注入(inject)攻击，准备好的语句也是如此。

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

1. 查询被解析成解析树
2. 参数用于规划查询
3. 计划执行
4. 提交数据以供返回。

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

第一个策略可能是服务器端准备好的语句。在这种情况下，计划将被保存并可能被重用，这可能会产生不希望的(或希望的)性能影响。

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

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

所以一般来说，我会说是的，即使使用最糟糕的方法，这也确实提供了类似的好处。

请注意，我一直在谈论顶级攻击。如果你在某处调用一个函数(例如从触发器)，你也可以在那里进行 SQL 注入(inject)。这发生在涉及动态 SQL 的地方，但通常不是问题。上述方法都不能防止这种情况发生，因为规划阶段将作为上述执行阶段的一个子部分发生，并且始终填写参数。

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