sp_executesql仅参数化值，不支持表名、列名和排序字段；动态对象名须用QUOTENAME()安全处理，排序等结构需白名单校验；禁用EXEC()，最小权限运行存储过程。
sp_executesql 参数化只保值，不保表名和排序字段
很多人以为用了 sp_executesql 就万事大吉，其实它只对传入的 **值（value）** 做参数化，比如 @status、@since 这类运行时数据。但表名、列名、ORDER BY 后的字段名、ASC/DESC 这些属于 SQL 语法结构，必须在编译前确定，数据库根本不允许用参数占位。
所以一旦你写成：ORDER BY ' + @sort_col + ' ' + @direction，哪怕后面用了 sp_executesql，攻击者传入 @sort_col = 'name; DROP TABLE logs; --'，照样执行恶意语句。
正确做法是：
- 只允许有限白名单，例如
IF @sort_col NOT IN ('id', 'name', 'created_at') THROW 50000, 'Invalid sort column', 1; - 用
CASE显式映射，避免字符串拼接：ORDER BY CASE @sort_col WHEN 'id' THEN id WHEN 'name' THEN name END - 方向控制必须独立校验：
IF @direction NOT IN ('ASC', 'DESC') SET @direction = 'ASC'，再拼进 SQL 字符串
QUOTENAME() 是唯一安全处理对象名的方式
当真要动态指定表名或架构名（比如多租户分表场景），不能靠 REPLACE(@table, '''', '''''') 或正则过滤，这些都可被绕过。SQL Server 提供了 QUOTENAME()，它会自动加方括号并转义内部特殊字符。
例如：QUOTENAME('user]; DROP TABLE x; --') 返回 [user]] DROP TABLE x; --]，这个结果作为标识符解析时直接报错，不会执行后续语句。
注意几个关键点：
-
QUOTENAME()只用于标识符（表名、列名、schema），绝不能用于值——值必须走sp_executesql参数 -
QUOTENAME(@schema) + '.' + QUOTENAME(@table)要分开调用，不能先拼字符串再套QUOTENAME()，否则校验失效 - 如果支持 schema，务必分别校验：
IF @schema NOT IN ('dbo', 'tenant_a') ...，再套QUOTENAME()
EXEC(@sql) 必须彻底禁用
EXEC(@sql) 完全不支持参数化，所有变量都得拼进字符串里，等于把执行权完全交给输入。只要用户能控制任意一个拼接点（哪怕只是 @where_cond），就构成高危路径。
常见错误模式：
SET @sql = 'SELECT * FROM ' + @table + ' WHERE name = ''' + @name + ''''; EXEC(@sql);- 即使后面改用
sp_executesql，但 SQL 字符串里仍含CAST(@id AS VARCHAR)—— 这种“伪参数化”毫无意义
强制替换方案：
- 所有动态值一律改为
@param占位符，例如WHERE status = @status AND created_at > @since - 参数声明字符串（如
N'@status TINYINT, @since DATETIME2'）必须与实际传参的类型、数量、顺序严格一致 - 开发阶段可用 SQL Server 的策略管理（Policy-Based Management）规则：禁止脚本中出现
EXEC(或未包裹QUOTENAME()的变量拼接
权限模型错位会让漏洞危害翻倍
即使代码写了 QUOTENAME() 和 sp_executesql，如果存储过程以 db_owner 或 sysadmin 身份运行，攻击者一旦突破某处校验（比如漏掉一个 IF 判断），就能执行 DROP、EXEC xp_cmdshell 等高危操作。
真实风险点在于：
- 存储过程默认继承调用者权限，但常被设为
EXECUTE AS OWNER或显式WITH EXECUTE AS 'sa' - 动态 SQL 在执行时使用的是存储过程定义者的上下文权限，不是调用者权限
建议动作：
- 存储过程一律用最小权限账户定义，例如仅授予
SELECT、INSERT到特定表 - 禁用
xp_cmdshell、sp_oacreate等扩展存储过程，除非业务强依赖且已隔离 - 上线前跑一次权限审计：查询
sys.database_permissions，确认无过度授权
真正难防的不是技术细节，而是元数据动态化需求和安全约束之间的拉扯——比如业务坚持要“按客户名自动切表”，又拒绝改前端逻辑。这种时候，白名单校验比 QUOTENAME() 更可靠，而把校验逻辑提到应用层做预过滤，往往比在存储过程中硬扛更可控。
