MySQL比PostgreSQL(在Perl/DBI下)更能抵抗SQL注入攻击吗?

默认情况下,MySQL客户机库似乎只限于每个调用一条语句(我在PHP中遇到过它)。

但这不应该成为在PostgreSQL上使用MySQL的原因,因为您仍然可以使用子查询进行注入。

防止注入攻击不是数据库的责任,而是开发人员的责任。如果开发人员编写的代码通过连接从用户输入中派生的字符串来创建查询,则结果查询将容易受到注入攻击,并且用于清理等的所有代码都是浪费时间的。如果代码是为使用参数化查询而编写的,并且用户输入被降级为用作参数值,则生成的查询将相当安全,不会受到注入攻击。(我很想知道如何通过参数值进行注入攻击)。

分享和享受。

不,事实上,MySQL几乎没有那么安全,在这种情况下,它看起来好像根本没有在服务器上完成准备语句。

准备好的语句支持(服务器 侧面准备)从3.0002_1开始,服务器 旁白在旁边 默认值(如果您的服务器是>=4.1.3)。 截至3.0009年,它们默认为关闭状态。 再次由于与准备的问题 语句API(所有其他MySQL 连接器按此方式设置,直到C API问题已解决)。这个 使用准备好的报表的要求 仍然保留服务器“>=4.1.3”

准备使用服务器端 语句,你所需要做的就是设置 变量mysql_server_prepare in 连接:

$dbh=dbi->连接( “dbi:mysql:database=test;host=localhost;mysql_server_prepare=1”, “”,“,raiseError=>1,自动提交 = & gt;1 };

• 注意:此参数的分隔符是';'

使用它有很多好处 服务器端准备语句,主要是 如果要执行许多插入操作 因为这个事实 声明准备接受 多个插入值。

确保“进行测试”步骤 测试服务器准备是否工作, 你只需要导出env 变量mysql_server_prepare:

导出mysql_server_prepare=1

大概,它们是在PostgreSQL的服务器上准备的。

就安全性而言,你只是做错了:使用 ? 如你所说。否则,你只是在利用Postgres可以准备多个语句:这不是什么负面的东西。我相信MySQL也可以做到这一点,这里唯一的区别是dbd::MySQL声称C API问题排除了服务器端准备的使用,因此它们依赖其他源作为服务器的权威。现在dbd::mysql可能在一个mysql库中使用c函数,这个库比mysql有服务器端准备(我猜是4.1.3之前的版本)。

如果不是不可能的话,有一个通用的SQL注入消毒剂可能是困难的。

添加了[正如注释所示,正确使用DBI,在DB客户机库的帮助下,可以在准备SQL语句时最小化注入。但是,必须记住,清理用户输入还涉及独立于所用数据库的应用程序逻辑。例如,使用其他用户的凭据可能会提供有效的 安全的 声明,但有意想不到的后果。不管怎样,这比问的问题要深入得多。]

删除[您最好自己清理输入,而不是对客户端抵抗这些类型的攻击有任何虚假安全感。不是说你不应该使用它们,只是不要假定它们提供的帮助不只是针对攻击的最小帮助。]