存储过程不能自动防止sql注入，只要内部动态拼接sql或调用端未参数化传参，仍会中招。需全程参数化、输入校验、最小权限及禁用高危功能。
存储过程内部拼接 SQL 时照样会中招
很多人误以为“用了存储过程就安全了”，其实只要在存储过程中用 EXEC、sp_executesql 或字符串拼接（比如 +' WHERE name = ''' + @name + ''''）动态构造 SQL，攻击者仍能通过传入恶意参数触发注入。典型场景包括：动态表名/列名查询、分页逻辑里拼接 ORDER BY 子句、多条件搜索的 WHERE 拼接。
常见错误现象：Msg 102, Level 15, State 1, Line 1 — Incorrect syntax near ' OR '1'='1' 这类报错本身可能不出现，但数据被绕过或篡改已发生。
- 参数化只对静态 SQL 生效；一旦进入
sp_executesql的 SQL 字符串体内部，变量值就不再受保护 -
QUOTENAME()只能安全包裹对象名（如表名、列名），不能用于值内容 - 数字型参数若未显式转换就拼进字符串，仍可能被绕过（例如
CAST(@id AS VARCHAR)后再拼接）
调用端没用参数化，存储过程白搭
存储过程本身是安全载体，但调用它的应用代码如果用字符串拼接方式传参（比如在 C# 中写 "EXEC GetUser @name = '" + input + "'"），那数据库层的参数声明完全失效——恶意输入早在抵达存储过程前就被注入进执行语句里了。
使用场景：ASP.NET WebForms 的旧式 SqlCommand 构造、PHP 的 mysqli_query("CALL sp_login('$user', '$pass')")、Java 的 Statement.execute("CALL login('" + user + "', '" + pass + "')")。
- 必须用
SqlCommand.Parameters.Add()、PreparedStatement.setXXX()等真正绑定参数的方式调用 - 即使存储过程定义了
@username NVARCHAR(50)，调用时拼接字符串等于直接废掉这层防护 - 某些 ORM（如早期 MyBatis 的 ${} 语法）也会跳过参数化，导致调用失守
权限控制不到位，注入后果更严重
存储过程常被赋予较高权限（比如 db_datawriter 或 EXECUTE 权限跨 schema），一旦被注入利用，攻击者可执行 DROP TABLE、INSERT INTO ... SELECT 甚至 xp_cmdshell（SQL Server）等高危操作。
性能 / 兼容性影响：过度依赖 EXECUTE AS OWNER 或 UNSAFE ASSEMBLY 会放大风险，且这类配置在云数据库（如 Azure SQL、RDS）中常被禁用或受限。
- 应遵循最小权限原则：为调用存储过程的账号单独授权，禁止授予
sysadmin或db_owner - 避免在存储过程中启用高危功能（如
OPENROWSET、OPENDATASOURCE），除非绝对必要 - SQL Server 中
EXECUTE AS CALLER比EXECUTE AS SELF更可控，但需确保调用者权限本身受限
容易被忽略的盲区：注释、编码与多语句
攻击者会利用注释符（--、/* */）、Unicode 编码（如 %u0027 替代单引号）、空字节截断，或在参数末尾注入分号触发堆叠查询（; DROP TABLE logs--）。这些手法在存储过程参数传入后依然生效，尤其当过程内有未校验的 IF 分支或日志记录逻辑时。
示例：一个日志存储过程接收 @action NVARCHAR(100)，内部执行 INSERT INTO audit_log VALUES (@action)，若该字段后续又被拼进另一条动态 SQL，则注入链成立。
- 所有输入参数都应做长度、字符集、业务语义三重校验，不能只依赖类型声明
- 避免在存储过程中记录原始用户输入到可执行上下文（如触发器、作业脚本、动态 SQL 日志表）
- SQL Server 的
SET QUOTED_IDENTIFIER OFF等会话级设置可能削弱QUOTENAME()效果，需统一约束
存储过程不是银弹，它只是把 SQL 注入的防线从应用层移到了数据库层——而这一层同样需要参数化、输入校验、权限收敛和行为审计。最危险的，是以为“写了存储过程”就等于“防住了注入”。
