sp_executesql是唯一真正支持参数化查询的机制，它通过显式声明参数类型与绑定值实现数据与代码隔离；而exec仅执行字符串，无法参数化，存在严重安全风险。
直接用 sp_executesql 参数化动态 SQL 是唯一靠谱的路径；用字符串拼接 + EXEC 或未参数化的 sp_executesql 都等于给攻击者开后门。
为什么不能用 EXEC 拼接用户输入
SQL Server 的 EXEC 不做任何参数解析，它把整个字符串当 T-SQL 执行。只要用户输入里带单引号、分号或 --，就可能提前闭合语句、注入新命令或注释掉校验逻辑。
- 典型错误写法：
DECLARE @sql NVARCHAR(MAX) = N'SELECT * FROM Users WHERE Name = ''' + @name + ''''; EXEC(@sql); - 攻击者传入
O'Neil→ 语句变成... WHERE Name = 'O'Neil'，语法错误；传入O''; DROP TABLE Users--就真删表了 - 即使加了
REPLACE(@name, '''', '''''')也防不住嵌套引号、Unicode 变体、或后续拼接到其他上下文（比如 ORDER BY 后）的场景
必须用 sp_executesql 并显式声明参数
sp_executesql 的设计目标就是安全执行动态 SQL：它强制分离代码和数据，参数值永远作为字面量传入，不会被解析为语句的一部分。
- 正确模板：
EXEC sp_executesql @sql, N'@param1 datatype, @param2 datatype', @param1 = @value1, @param2 = @value2; - 所有用户可控变量（包括
@orderby、@top等非 WHERE 条件）都不能直接拼进@sql字符串 - 如果真要动态列名或表名（如
ORDER BY @col），必须先白名单校验：IF @col NOT IN ('Name', 'Email', 'CreatedDate') THROW 50000, 'Invalid column', 1; -
@top这类数字参数要用INT类型传入，别转成字符串再拼 —— 防止绕过数字校验
存储过程里调用动态 SQL 的常见陷阱
很多人以为“用了存储过程就天然防注入”，其实错在混淆了“过程封装”和“参数化执行”。存储过程本身不免疫，关键看内部怎么执行动态 SQL。
- 错误：过程参数是
@search NVARCHAR(50)，但内部仍拼接：SET @sql = 'WHERE Title LIKE ''%' + @search + '%''' - 正确：把
@search当参数传给sp_executesql，LIKE 模式在 SQL 字符串里写死：WHERE Title LIKE ''%'' + @search + ''%''（注意：这里@search是参数，不是拼进去的字符串） - 输出参数和返回状态也要检查：
sp_executesql执行失败不会自动抛异常，需查@@ERROR或用TRY/CATCH - 别在动态 SQL 里调用
xp_cmdshell、OPENROWSET等高危系统过程 —— 即使参数化，权限失控也会放大风险
额外加固点：权限与加密边界
参数化解决的是“语句执行时的数据污染”，但无法替代最小权限原则和静态数据保护。
- 执行存储过程的数据库账户，不应有
db_owner或sysadmin角色；只授予过程本身EXECUTE权限即可 - 敏感字段（如身份证、手机号）优先启用
Always Encrypted，让加密/解密完全发生在客户端 —— 即使 SQL 注入成功，拿到的也只是密文 - 避免在错误消息里暴露表名、列名或 SQL 片段（例如
RAISERROR不要含@sql内容），防止攻击者探测结构 - 如果必须用动态 SQL 做多租户隔离（如拼接不同客户表名），表名必须严格匹配预定义列表，且禁止任何通配符或正则绕过
最易被忽略的一点：动态 SQL 的参数化不是“写了 sp_executesql 就算完事”，而是每一处用户输入都得进参数列表 —— 包括你以为“只是数字所以安全”的 @page、@pagesize，它们一旦被转成字符串拼接，就立刻退化成拼接漏洞。
