如何在SQL Server中利用存储过程封装降低注入面

必须用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 或报错，但这个“转”本身就是逻辑漏洞的起点。