首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >当涉及到防范SQL注入时,PG::Connection#exec_params是否与使用准备好的语句相同?

当涉及到防范SQL注入时,PG::Connection#exec_params是否与使用准备好的语句相同?
EN

Stack Overflow用户
提问于 2017-02-16 17:30:35
回答 1查看 268关注 0票数 4

准备好的语句是获接纳提供了很好的保护,防止SQL注入,并且使用PG::Connection#exec手动向sql查询中注入变量是邪恶,并且永远不会执行

但是参数呢?与准备好的语句相比,它是否提供了与sql注入相同的保护级别?

如果它确实提供了防止sql注入的保护,那么它总是正确的还是只有当您显式地绑定参数时才是真的?

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2017-02-16 17:54:11

是的博士。

我不知道Ruby驱动程序的内部细节。不过,我认为它可以使用三种策略。理论上只有一个可以攻击顶级SQL注入攻击(下面将详细介绍),但所有攻击都可能受到低级SQL注入攻击,正如准备好的语句一样。

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

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

在预先准备好的声明中,计划被保存,但这并不是使它们安全的原因。对于顶级攻击,它们之所以安全,是因为参数是独立于要解析的查询发送的。

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

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

第三,你可以让客户端逃跑。这仍然比您自己做的任何事情都安全,因为它可能位于中心位置等等。我知道Perl的DBD::Pg可以回到这个位置,但几乎从来没有。我没有看到任何退路,但也许有一次我错过了。

因此,总的来说,我会说是的,这确实提供了类似的好处,即使使用最坏的方法。

注意我一直在说顶级攻击。如果您在某个地方(例如,从触发器)调用一个函数,您也可以在其中进行SQL注入。这种情况发生在涉及动态SQL的地方,但通常不是问题。上述任何一种方法都不能防止这一点,因为计划阶段将作为上面执行阶段的一个子部分发生,并且参数总是被填充。

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

票数 3
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/42280917

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档