存储过程EXEC动态SQL的二次注入解决方案

SQL二次注入高危入口：EXEC(@sql)风险解析与防范要点

首先需要明确：EXEC(@sql) 本质上是一个“黑箱操作”——它直接将字符串作为 SQL 命令执行，数据库无法区分“哪部分是结构指令，哪部分是普通数据”。这就引发了一个极为危险的场景：即使你从数据库读到的是用户名字段，表面上看似正常，但只要其中包含了类似 ' OR 1=1 -- 的内容，一旦被拼接进 @sql，立刻就会变成真正可执行的恶意代码。

来看一个典型的错误示例：EXEC('SELECT * FROM users WHERE name = ''' + @name + '''')。这里的 @name 取自之前查询的结果，你或许觉得没有问题，但隐患恰恰在于没有做任何隔离处理。

以下几个原则必须牢记：

• 即使 @name 来源于 sys.tables 这类系统视图，也绝不能默认它是安全的。
• QUOTENAME() 函数仅负责转义括号和单引号，无法防御 ]; DROP TABLE x; -- 这类收尾式注入攻击。
• 所有拼入 @sql 的变量——无论是用户输入、数据库读取还是配置文件中的值——都必须视为不可信数据来处理。

换用sp_executesql并非终点，参数绑定必须到位

许多开发者知道改用 sp_executesql，却误以为“换了就安全了”——这是一个常见误区。它只有在同时满足三个条件时才能真正起到防护作用：SQL 模板中不写死具体数值、参数类型显式声明、参数值独立传入。

一个完整的正确写法分为三部分：

DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM users WHERE status = @status AND created_at > @since';
DECLARE @params NVARCHAR(MAX) = N'@status TINYINT, @since DATETIME2(0)';
EXEC sp_executesql @sql, @params, @status = 1, @since = '2024-01-01';

这里有几点需要特别注意：

• @sql 中不得出现任何变量值，只能使用 @param 这样的占位符。
• @params 字符串必须写全类型——例如 @status TINYINT 不能简写为 @status。
• 第三个参数列表必须带等号，比如 @status = 1，不能只写 1 或 @status。
• 如果参数是字符串类型，建议限制长度，比如 @name NVARCHAR(50)，避免使用 MAX 类型绕过校验。

动态对象名（表名/列名）——只有一条路，但必须锁死

SQL Server 不支持将表名或列名直接作为参数传递给 sp_executesql，因此只能硬拼接。但这条路径并非无条件开放，必须配合严格的校验。

一种错误的做法是：SET @sql = 'SELECT * FROM ' + QUOTENAME(@table_name)。原因很简单——QUOTENAME 仅转义括号和引号，不验证表名是否真实存在、是否属于预期的 schema。

正确的做法包含两个步骤：

• 先查询系统视图，确认表存在且归属预期的 schema：IF NOT EXISTS (SELECT 1 FROM sys.tables t JOIN sys.schemas s ON t.schema_id = s.schema_id WHERE s.name = 'dbo' AND t.name = @table_name)。这一步确保表名不仅合规，而且确实存在。
• 排序字段等采用硬编码白名单：IF @sort_col NOT IN ('id', 'created_at', 'status') THROW 50000, 'Invalid sort column', 1。不要图省事。

这里有一个额外要注意的坑：不要单独使用 OBJECT_ID(@table_name) 判断。因为它不校验 schema，恶意输入如 users; DROP TABLE logs; -- 可能被截断后误判为合法，后果非常严重。

从数据库读出的数据再进查询前，必须重新校验

二次注入最致命的思维陷阱是什么？就是开发者认为“数据已经入库了，肯定没问题”。但数据库只是一个存储容器，不负责语义安全——存进去的是什么，取出来的就是什么。

因此，从防御角度出发：

• 即使数据来自内部管理后台，也应按输入规则重新校验一遍：包括长度、字符集、正则模式（例如 @name NOT LIKE '%[^a-zA-Z0-9_]%'）。
• 对数字类参数，开头增加范围检查：IF @user_id < 1 OR @user_id > 999999 RETURN。
• 禁止在过程中使用 CAST(@input AS NVARCHAR) 或 CONVERT 后再拼接——转换失败会报错，成功后数据可能失真，甚至绕过前期校验。
• 如果业务逻辑确实需要拼接（比如动态 WHERE 条件），尽量拆成多个预定义分支，而不是依赖字符串拼接兜底。

最危险的情况是什么？不是不知道要防范，而是以为用了 sp_executesql 就可以高枕无忧。参数类型过宽、对象名校验缺失、读库数据未重检——任何一个环节松动，都等于为二次注入留了一扇后门。