必须用sp_executesql代替exec实现参数化，严格声明参数类型与长度；动态对象名须白名单校验+quotename()封装；参数声明要窄、强、带范围检查；权限最小化并搭配视图使用。
存储过程本身不防注入，但能大幅收窄攻击面——前提是不用字符串拼接、参数类型明确、权限卡死。
SQL Server 存储过程里别用 EXEC(@sql) 拼接
EXEC 直接执行字符串，所有变量拼进去就等于把用户输入喂给 SQL 引擎。哪怕加了 REPLACE 或 QUOTENAME，也挡不住 ]; DROP TABLE users; -- 这类结尾注入。
- 必须改用
sp_executesql，它支持真正的参数绑定 -
@sql字符串里只写结构，比如N'SELECT * FROM users WHERE status = @status'，不能出现任何变量值 - 第二个参数是类型声明，必须写全，例如
N'@status TINYINT'，不能只写N'@status' - 第三个及之后的参数才是传值，且顺序、类型、长度要和声明严格一致
参数声明必须窄，别用 NVARCHAR(MAX) 或 SQL_VARIANT
宽泛类型会让上游传参失控，比如 @name NVARCHAR(MAX) 允许传入 2GB 的恶意 payload，后续校验可能被绕过或崩溃。
- 数字类参数直接用
INT、TINYINT，并在开头加范围检查：IF @id 999999 RETURN - 字符串类参数限定长度：
@username NVARCHAR(50)，再加内容校验：LEN(@username) > 0 AND @username NOT LIKE '%[^a-zA-Z0-9_ ]%' - 避免在过程内做
TRY_CAST或CONVERT处理用户输入——转换失败报错，转换成功却可能已失真
表名、列名、排序字段这些不能参数化，必须白名单
SQL Server 不允许 WHERE 后面的字段名或 FROM 后的表名用 @param 占位，硬拼就是高危操作。
- 禁用
SET @sql = 'SELECT * FROM ' + @table_name这类写法 - 若真需动态对象名，先查
sys.tables确认存在，再用QUOTENAME(@table_name)包裹（仅限标识符，不用于值） - 更稳妥的做法是白名单硬编码：
CASE WHEN @sort_col IN ('name', 'email', 'created_at') THEN @sort_col ELSE THROW 50000, 'Invalid sort column', 1 END - 别信“过滤掉单引号就安全”——攻击者用
CHAR(39)、Unicode 变体或注释符就能绕过
视图 + 权限最小化才是存储过程的真正护城河
就算存储过程写得滴水不漏，如果账号有 db_owner 或能跨库查询，一次注入仍可能拖库。
- 建完存储过程后，立刻
REVOKE SELECT ON users FROM app_user，只授EXECUTE ON GetUsersByStatus - 搭配视图使用：建
v_active_users只暴露必要字段，然后GRANT SELECT ON v_active_users TO app_user - 确认权限没被角色继承意外放大——必须显式
GRANT EXECUTE ON OBJECT::dbo.GetUser，别依赖db_executor
最常被忽略的一点：存储过程的安全性高度依赖调用层。如果应用代码把 Request.Query["id"] 直接当 INT 传进来，却不校验是否为纯数字，那过程内部再严也没用——恶意字符串进到 @id 里，SQL Server 会隐式转成 0 或报错，但这个“转”本身就是逻辑漏洞的起点。
