如何保护该函数免受 SQL 注入？

Question

public static bool TruncateTable(string dbAlias, string tableName)
{
    string sqlStatement = string.Format("TRUNCATE TABLE {0}", tableName);
    return ExecuteNonQuery(dbAlias, sqlStatement) > 0;
}

Answer 1

对抗 SQL 注入的最常见建议是使用 SQL 查询参数（该线程上的几个人都建议这样做）。

在本例中这是错误的答案。您不能在 DDL 语句中对表名使用 SQL 查询参数。

SQL 查询参数只能用于代替 SQL 表达式中的文字值。这是每个 SQL 实现的标准。

当您有表名时，我建议防止 SQL 注入是根据已知表名列表验证输入字符串。

您可以从 INFORMATION_SCHEMA 获取有效表名的列​​表：

SELECT table_name 
FROM INFORMATION_SCHEMA.Tables 
WHERE table_type = 'BASE TABLE'
  AND table_name = @tableName

现在您可以将输入变量作为 SQL 参数传递给此查询。如果查询未返回任何行，则您知道输入无效，无法用作表。如果查询返回一行，则它匹配，因此您可以更放心地使用它。

您还可以根据您定义为可以让应用程序截断的特定表列表来验证表名称，如 @John Buchanan 建议。

即使在验证 tableName 作为 RDBMS 中的表名称存在之后，我也建议对表名称进行分隔，以防万一您使用带有空格或特殊字符的表名称。在 Microsoft SQL Server 中，默认标识符分隔符是方括号：

string sqlStatement = string.Format("TRUNCATE TABLE [{0}]", tableName);

现在，只有当 tableName 与真实表匹配时，您才会面临 SQL 注入的风险，并且您实际上在表名称中使用了方括号！

Answer 2

据我所知，不能使用参数化查询来执行DDL语句/指定表名，至少在Oracle或Sql Server中不能。如果我必须有一个疯狂的 TruncateTable 函数，并且必须能够避免 SQL 注入，我会做的就是创建一个存储过程来检查输入是否是可以安全截断的表。

-- Sql Server specific!
CREATE TABLE TruncableTables (TableName varchar(50))
Insert into TruncableTables values ('MyTable')

go

CREATE PROCEDURE MyTrunc @tableName varchar(50)
AS
BEGIN

declare @IsValidTable int
declare @SqlString nvarchar(50)
select @IsValidTable = Count(*) from TruncableTables where TableName = @tableName

if @IsValidTable > 0
begin
 select @SqlString = 'truncate table ' + @tableName
 EXECUTE sp_executesql @SqlString
end
END

Answer 3

如果您允许用户定义的输入通过表名变量渗透到此函数中，我不认为 SQL 注入是您唯一的问题。

更好的选择是通过自己的安全连接运行此命令，并且根本不授予它 SELECT 权限。 TRUNCATE 运行所需的只是 ALTER TABLE 权限。如果您使用的是 SQL 2005 以上版本，您还可以尝试使用内部包含 EXECUTE AS 的存储过程。

Answer 4

CREATE OR REPLACE PROCEDURE truncate(ptbl_name IN VARCHAR2) IS
  stmt VARCHAR2(100);
BEGIN
  stmt := 'TRUNCATE TABLE '||DBMS_ASSERT.SIMPLE_SQL_NAME(ptbl_name);
  dbms_output.put_line('<'||stmt||'>');
  EXECUTE IMMEDIATE stmt;
END;

Answer 5

使用存储过程。任何像样的数据库库（我使用的是 MS Enterprise Library）都可以正确处理转义字符串参数。

另外，重新：参数化查询：我宁愿不必重新部署我的应用程序来修复数据库问题。将查询作为文字字符串存储在源中会增加维护复杂性。

Answer 6

查看此链接

此代码是否可以防止 SQL 注入？

删除不需要的内容来自表名字符串。

我认为您不能使用参数查询作为表名。

Answer 7

还有一些其他帖子将有助于 SQL 注入，因此我将投票支持这些帖子，但另一件事需要考虑的是您将如何处理此操作的权限。如果您授予用户 db+owner 或 db_ddladmin 角色以便他们可以截断表，那么仅仅避免标准 SQL 注入攻击是不够的。黑客可以发送其他可能有效但您不希望被截断的表名称。

如果您向允许截断的特定表上的用户授予 ALTER TABLE 权限，那么您的情况会好一点，但仍然超出了我在正常环境中允许的范围。

通常，在正常的日常应用程序使用中不会使用 TRUNCATE TABLE。它用于 ETL 场景或数据库维护期间。我想象它会在前端应用程序中使用的唯一情况是，如果您允许用户加载特定于该用户的表以用于加载目的，但即使如此，我也可能会使用不同的解决方案。

当然，在不知道您使用它的具体原因的情况下，我不能断然地说您应该重新设计，但如果我作为 DBA 收到这样的请求，我会问开发人员很多问题。

Answer 8

使用参数化查询。

Answer 9

在这个具体示例中，仅当表名来自外部源时，您才需要防止 SQL 注入。

你为什么会允许这种事发生？
如果您允许某些外部实体（最终用户、其他系统，什么？）
要命名要删除的表，为什么不直接授予他们管理员权限。

如果您要创建和删除表以便为最终用户提供某些功能，
不要让他们直接提供数据库对象的名称。
除了 SQL 注入之外，您还会遇到名称冲突等问题。
相反，您自己生成真实的表名称（例如 DYNTABLE_00001、DYNTABLE_00002，...）并保留一个将它们连接到用户提供的名称的表。

---

关于为 DDL 操作生成动态 SQL 的一些注意事项：

• 在大多数 RDBMS 中，您必须使用动态 SQL 并将表名称作为文本插入。
  要格外小心。

• 使用带引号的标识符（MS SQL Server 中为 []，所有符合 ANSI 的 RDBMS 中为 ""）。
  这将更容易避免由无效名称引起的错误。

• 在存储过程中执行此操作，并检查所有引用的对象是否有效。

• 不要做任何不可挽回的事情。例如，不要自动删除表。
  您可以将它们标记为删除并向您的 DBA 发送电子邮件。
  备份后她会删除它们。

• 如果可以的话，避免它。如果做不到，请尽您所能尽量减少他人的权利
  普通用户将拥有的（非动态）表。

Answer 10

您可以使用 SQLParameter 传入 tableName价值。据我所知和测试，SQLParameter 负责所有参数检查，从而禁用注入的可能性。

Answer 11

如果您不能使用参数化查询（并且您应该）...将 ' 的所有实例简单替换为 '' 应该可以。

string sqlStatement = string.Format("TRUNCATE TABLE {0}", tableName.Replace("'", "''"));