perl函数dbh->引号仍然安全吗？

Question

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

我使用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;
}
...

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

经过一番挖掘，我发现本文件(pdf)似乎在谈论它，但我无法重现这个bug。

Answer 1

问题主要不在于quote本身。如果使用得当，quote是安全的(尽管在这种情况下它不是最好的选择)。但是，如果param是来自CGI.pm的param，或者其他具有类似行为的东西，那么您就有了一个大问题。

你看，param是对上下文敏感的。在标量上下文中，如果参数有单个值(name=foo)，则返回该值，如果参数具有多个值(name=foo&name=bar)，则返回数组。在列表上下文中，它返回一个值列表，无论是零、一还是多。方法(如quote)的参数列表是列表上下文。这意味着，使用您的应用程序的人可以使quote接收两个值，而quote的可选的第二个参数是第一个参数应该被视为的SQL数据类型。如果数据类型是NUMERIC这样的非字符串类型，那么quote将传递其第一个参数，而不需要任何引用。这为SQL注入提供了一个机会。

建议：

1. 虽然quote在正确使用时是安全的，但是占位符更好、更安全、更难使用错误。尽可能使用DBI占位符，而不是quote。
2. 不要在参数列表、散列构造函数或任何其他地方使用CGI的param，因为这些地方可能会返回一些意想不到的项目并破坏您的一天。要么把scalar放在前面，分配给标量，要么分配给数组。或者，更好的是，完全避免CGI.pm和类似工作的接口。
3. 不要将密码以明文形式存储在数据库中。如果有人能够访问数据库的一部分，您的用户的密码就会暴露给他们。密码应该是散列，并且有很好的、易于使用的Perl模块(想到了奥森：：密码)。
4. 不要将密码作为URL参数传递。URL很容易通过HTTP引用、浏览器历史记录、不小心复制/粘贴等泄露。密码应该是POSTed格式的，最好是通过安全连接。

Answer 2

您可能希望与dbi-用户邮件列表联系，询问存在哪些漏洞。添加一个引号并不会让事情变得更糟，只要你是在逃避它们。您仍然要确保您知道所有的SQL注入攻击。您还可能希望避免将密码作为url参数传递(更喜欢POST请求)，因为url(以及任何params)都不是加密的，而且很容易读取。