sql - perl 函数 dbh->quote 仍然安全吗？

Question

我目前正在用 perl 编写一个小脚本来连接到我的数据库，检索一些数据，并将其显示给用户。检索到的数据取决于用户给出的参数。

我正在使用 dbh->quote转义引号:

...
my $dbh=DBI->connect(***);

my $myquery="SELECT * FROM customers WHERE clientName =".$dbh->quote(param('name')) . " AND pass =".$dbh->quote(param('pass'));
my $sth=$dbh->prepare($myquery);
$sth->execute();

my $output=$sth->fetch();
if ($output){
    print @$output;
}
...

一个 friend 告诉我它可能不安全，他读到有人发现了一个漏洞。我刚开始使用 perl，但是 我想了解那个漏洞是什么。

经过一番挖掘，我找到了 this document (pdf)这似乎在谈论它，但我无法重现该错误。

Answer 1

问题主要不在于quote本身。 quote如果使用得当，它是安全的(尽管在这种情况下它不是最佳选择)。但是，如果 param是 param从 CGI.pm 或其他任何具有类似行为的文件中，您会遇到大问题。

你看，param是上下文相关的。在标量上下文中，如果参数具有单个值( name=foo )，则返回该值，如果参数具有多个值( name=foo&name=bar )，则返回一个数组引用。在列表上下文中，它返回一个值列表，无论是零、一还是多个。方法的参数列表(例如 quote )是一个列表上下文。这意味着有人使用您的应用程序可能会导致 quote接收两个值，和 quote的可选第二个参数是第一个参数应视为的 SQL 数据类型。如果数据类型是非字符串类型，如 NUMERIC ，然后 quote将通过它的第一个参数而不进行任何引用。这构成了 SQL 注入(inject)的机会。

建议:

虽然 quote正确使用是安全的，占位符更好，更安全，更难使用错误。尽可能使用 DBI 占位符，而不是 quote .

不要使用 CGI 的 param在参数列表、哈希构造函数或任何其他可能返回意外数量的项目并毁了你一天的地方。要么放 scalar在前面，分配给标量或分配给数组。或者，更好的是，完全避免 CGI.pm 和类似工作的界面。

不要将密码作为明文存储在数据库中。如果有人确实可以访问您数据库的某些部分，您的用户的密码就会暴露给他们。密码应该是 hashed并且有很好的、易于使用的 Perl 模块来这样做(我想到了 Authen::Passphrase)。

不要将密码作为 URL 参数传递。 URL 很容易通过 HTTP 引用、浏览器历史记录、粗心的复制/粘贴等泄露。密码应该以表格形式发布，最好通过安全连接。