存储过程本身不防SQL注入，关键在于是否安全编写；若内部拼接用户输入（如EXEC(@sql)或CONCAT），仍会中招，必须使用参数化方式（如sp_executesql配合显式参数绑定）或静态SQL。
存储过程本身不免疫SQL注入
很多人误以为只要用了 CREATE PROCEDURE，就天然防注入——其实完全不是。存储过程只是把SQL逻辑封装起来，如果内部仍用字符串拼接构造动态查询，风险一点没少。关键看它怎么写，而不是它叫不叫“存储过程”。
动态拼接 EXEC(@sql) 是高危操作
在 SQL Server 中，EXEC(@sql) 或 sp_executesql @sql 如果参数来自用户输入且未经处理，就是典型的注入入口。哪怕整个逻辑都在存储过程里，只要最终执行的语句是拼出来的，攻击者就能塞进 UNION SELECT、WAITFOR DELAY 甚至 DROP TABLE。
-
@sql变量若由username + ''' OR 1=1 --'拼接而来，EXEC会照单全收 -
sp_executesql本身支持参数化，但必须显式传参；如果只传一个拼好的字符串进去，等于白搭 - MySQL 的
PREPARE stmt FROM @sql+EXECUTE stmt同理，拼接即危险
参数化 ≠ 存储过程自动参数化
存储过程的输入参数（如 @name NVARCHAR(50)）本身是安全的，但仅限于它们被直接用于 WHERE 条件等静态上下文。一旦你用这些参数去拼 @sql，再 EXEC，那参数就退化成普通字符串了。
正确做法是：用 sp_executesql 的参数绑定机制，把用户输入作为参数传进去，而不是拼进 SQL 字符串里。例如：
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM users WHERE name = @name'; EXEC sp_executesql @sql, N'@name NVARCHAR(50)', @name = @input;
这里 @input 是受控参数，不会被解析为代码。
权限控制和错误信息暴露会放大风险
即使存储过程里没拼接，如果它用的是高权限账号（比如 sa），或者开启详细错误（SET ARITHABORT ON 导致报错泄露表结构），攻击者就能靠盲注或错误型注入逐步探出数据。存储过程不自带最小权限，也不自动屏蔽错误细节。
- 数据库账号应只具备该存储过程所需的最低权限，比如仅
SELECT某几张表 - 避免在生产环境返回原始 SQL 错误，尤其不能让
Msg 102或表名字段名直接暴露给前端 - 日志中记录的是调用参数，不是拼出来的完整 SQL —— 否则等于帮攻击者留证据
真正容易被忽略的，是开发者常把“写了存储过程”当成安全结项标志，却没检查里面有没有一行 SET @sql = 'SELECT ... ' + @user_input。注入不发生在语法层面，而发生在执行时字符串如何落地。
