pgsql无法执行sql语句

Posted 2023-05-16

参考技术A 可以查看所有正在运行的mysql中的线程；找到你所要终止的线程id；比如是 145623；
执行：kill 145623; 就可以了。当然假如你的sql是比如alter table 一张大表，或者在delete一张大表等等之类的操作的时候，只有耐心等待了。这时候如果真的想要强行停止，只有停mysql实例了，不过这时候可能会表损坏丢数据等等。

pl/pgsql 与针对 sql 注入攻击的准备好的语句

【中文标题】pl/pgsql 与针对 sql 注入攻击的准备好的语句

【英文标题】：pl/pgsql vs prepared statements against sql injection attacks

【发布时间】：2018-07-05 00:38:51

【问题描述】：

我对预处理语句有更多经验，并且我知道它们非常适合抵御 SQL 注入攻击。

我想知道 pl/pgsql 的 format/USING 和 quote_literal/quote_nullable 是否同样有效，因为准备好的语句也有一些漏洞（检查 here 和 here）。

那么，pl/pgsql 的安全性与准备好的语句相同吗？我应该考虑自己的安全并被format/USING / quote_literal/quote_nullable 覆盖，还是我必须做更多，才能更安全？

【问题讨论】：

format+using 的设计考虑到了注入 - 我会说它在 postgres 中是一样安全的。您的链接没有显示准​​备好的声明漏洞 - 它们显示了尽管准备好的声明安全，但糟糕的设计会如何成功。好吧 - 格式也不会保存在这里

是的，我添加了这些链接以表明准备好的语句不安全，尤其是如果您不知道自己在做什么。谢谢

难道 format+using 等于 quote_literall，因为：(a) 格式的 L 等价于 quote_nullable (here) 和 (b) quote_nullable 的工作方式与quote_literal (here)

plpgsql vspre​​pared statements 是错误的二分法，因为 plpgsql 代码必须始终由查询调用。如果该查询受到 sql 注入的影响，则在到达 plpgsql 代码之前游戏就结束了。问题是错误的。这就像在汽车里问，轮胎好还是刹车好。

@DanielVérité 但调用 plpgsql 的查询可能是安全的，并且 plpgsql 中的查询可能存在语法错误，使其容易受到注射……汽车可能有新的、好的轮胎并且没有断裂完全...

【参考方案1】：

EXECUTE 和USING 在 PL/pgSQL 中是 100% 免受 SQL 注入的。 你引用的例子不相关。

只有正确地引用才是安全的。这就是为什么它不如使用参数。

使用USING 的带有占位符的语句将作为准备好的语句处理，而提供给USING 的参数将成为准备好的语句的参数。参数中的文本从不作为 SQL 语句的一部分进行解析，因此不可能进行 SQL 注入。

【讨论】：

是的，我添加链接只是为了表明有时准备好的语句会带来风险，尤其是如果您不知道如何编写它们的语法。另外...不是格式+使用等于quote_literall，因为：（a）格式的L等于quote_nullable（here）和（b）quote_nullable与quote_literal工作相同（ here)...所以我猜格式+使用 = quote_literall ？不？谢谢

它们有些相似。如果您忘记使用quote_* 或在错误的地方使用%s 格式，那么您很容易受到攻击。

文档再次让我对使用感到困惑。使用“因为不需要引用或转义，所以不太容易受到 SQL 注入攻击”。 here 。如果没有引用/转义，使用如何安全？我是否可以得出结论 EXECUTE/format/USING 根据 this 被 SPI_prepare 翻译成准备好的语句？ SPI_prepare 是否也适用于动态 EXECUTE 查询？

说 USING “不太容易 受到 SQL 注入攻击”就像说它可能会受到攻击。我不知道 quote_literal 的引用/转义是否比不引用/转义的 EXECUTE/format/USING 更好或更差，而且我无法自己测试它。我断定SPI_prepare不申请EXECUTE，所以在这里追尾。

不，意思是EXECUTE 'SELECT $1' USING myvar;和SELECT myvar;一样。