Perl 防止SQL表名注入-多远就是太远？

我正在开发一个相对较小的应用程序来与PostgreSQL对话，并希望获得一些反馈，说明在防止SQL注入方面，有多远还远远不够

该应用程序使用Perl，不使用任何ORM模块（仅使用DBI）。SQL语句以典型的方式构造，带有占位符：

my $sql = "SELECT * FROM $cfg->{tablename} WHERE foo = ?";
my $sth = $dbh->prepare($sql);
$sth->execute('bar');

插入表名的原因是应用程序必须对多个表执行相同的操作，所有表都有一列“foo”

使用？占位符可以防止大多数简单的SQL注入攻击。我的问题是关于表名，你不能使用占位符。该表来自配置文件，但应用程序支持--configfile开关以使用备用配置文件

数据库凭据存储在配置文件中。因此，如果攻击者可以创建一个配置文件（或替换默认文件），其中$cfg->{tablename}被替换为恶意代码，那么应用程序可能会被“诱骗”运行恶意代码

对于攻击者来说，他们必须已经拥有有效的数据库凭据，否则应用程序将无法连接。如果他们有凭证，那么他们可以使用DBI手工编写自己的代码，或者使用psql cli进行恶意操作

我认为有两种可能的方法可以防止这种情况：

• 切换到ORM，在这种情况下，我将按照$ORM->get_class_for_table（$cfg->{tablename}的顺序执行一些操作
• 在准备SQL语句之前，使用正则表达式清理表名
• 使用$dbh->quote_identifier（）

显然，第二种方式是“廉价而愉快”的。但是，如果给出了上面的凭证，这些方法是否都是合理的？当强迫攻击者使用一个备用的攻击向量（而不是实际阻止攻击的努力）时，付出多少努力？< /P> < P>使用：

---

在这些情况下，我创建自己版本的占位符，并检查将插入的值作为表名，以确保它是我期望的表名。这意味着不仅仅是检查表是否存在；某些操作应该只影响某些表，而不影响其他表

---

我不会使用正则表达式对名称进行清理。要么他们做对了，并且它在您允许的名称列表中，要么他们搞错了，您给了他们一个错误。

我更新了问题，以反映这是一种可能性（这是另一种进行正则表达式样式清理的方法）但是，我真正的问题仍然是：如果攻击者处于quote_identifier可以保存您的位置，那么他们可以通过psql执行相同的操作。当然，它不会从知道DB登录和传递的攻击者那里保存您。但它会创建更多的防愚应用程序。如果DB登录数据存储在其他位置，它将从attac获得帮助ks.Between，quote_标识符（）不会从表名中删除符号，它只是将符号（如引号）转义，并用与数据库相对应的引号将名称括起来。一个有趣的细节：quote_标识符不适用于Oracle。如果攻击者已经可以重写配置文件并连接到数据库……为什么他们要通过您进行SQL注入攻击r应用程序？当前门打开时，你正在登上二层楼的窗户。这正是我的问题-当动态SQL不能真正提高安全性时，是否值得从动态SQL切换到ORM。我正面临这样做的压力，希望有更多的论据反对我的问题中已经存在的技术方法消毒（正则表达式消毒）

my $sql = "SELECT * FROM ".
  $dbh->quote_identifier($cfg->{tablename}).
  " WHERE foo = ?";