MySQL 是否比 PostgreSQL（在 Perl/DBI 下）更能抵抗 SQL 注入攻击？

我正在审查一个基于 Linux 的 Perl Web 应用程序，其中包含一个具有普遍存在的登录处理程序

my $sth = $DB->prepare("从 userid='$userid' 的密码中选择密码") 或死； $sth->执行或死亡； ...

其中 $userid 是根据（不安全、未过滤的）Web 用户输入初始化的。

众所周知，DBI 文档建议将此代码更改为使用占位符“?”为了安全起见，代替“$userid”。

出于安全审查的目的，该代码按原样隔离在离网设备上。互联网服务器上的此类代码最终将被破解，因为现在有机器人扫描此漏洞。访问控制对于保护任何重要内容也是无效的，因为已知的注入可以删除数据库、插入不良数据或新用户，或者绕过访问控制以允许访问 Web 应用程序。

由于应用程序可以配置为使用 PostgreSQL 或 MySQL，并且提出了有关比较漏洞的问题，因此我尝试了这两个数据库，并通过一些 SQL 注入尝试测试了每个配置。

在 PostgreSQL 下输入 ';在这里做坏事；和这里;会按预期崩溃登录 cgi 并执行坏的东西。

出乎意料的是MySQL竟然抵抗住了这次攻击。这让我想知道 DBD::MySQL 或其他地方是否有某种设置限制每次调用准备 1 个语句，或者 MySQL 以其他方式抵抗。

据我了解，MySQL 通常不抵抗 SQL 注入。

这不仅仅是一个关于消除 SQL 注入技术的问题；而是一个关于消除 SQL 注入的技术问题。为此也许请参阅如何避免SQL注入攻击？.

问题是：在 PERL DBI 下，MySQL 是否比 PostgreSQL 更能抵抗 SQL 注入攻击？为什么会出现这种情况？

防范注入攻击不是数据库的责任，而是开发人员的责任。如果开发人员编写通过连接从用户输入派生的字符串来创建查询的代码，则生成的查询将容易受到注入攻击，并且所有用于清理等的代码，恕我直言都是浪费时间。如果编写代码以使用参数化查询，并且将用户输入降级为用作参数值，则生成的查询将相当安全，免受注入攻击。 （我有兴趣了解如何通过参数值进行注入攻击）。

分享并享受。