先说一个核心判断：存储过程并非万能的SQL注入免疫工具，但堪称一道可靠的安全防线。恰当运用，可大幅收窄攻击入口；运用不当，则形同虚设。关键在于充分理解其在安全防护中的实际能力与局限性。
业界普遍认为，存储过程通过强制分离数据与逻辑，有效降低了注入风险。但前提是开发过程中需严格遵循一系列安全规范。
关键一：杜绝EXEC(@sql)字符串拼接，采用sp_executesql参数化查询
直接使用EXEC拼接字符串，相当于将用户输入作为SQL指令执行，风险极高。即使用了REPLACE或QUOTENAME进行过滤，依然难以抵御诸如（]; DROP TABLE users; --）形式的结尾注入，这已是业内公认的隐患。
- 正确做法是切换至
sp_executesql，该函数支持真正的参数绑定机制。 @sql字符串中仅包含查询结构，例如N'SELECT * FROM users WHERE status = @status'，严禁将变量值嵌入其中。- 第二个参数需完整声明类型，如
N'@status TINYINT'，不可仅填写参数名。 - 第三个及之后的参数用于传入实际值，顺序、类型及长度必须与声明严格对应，不可疏忽。
关键二：严格限定参数类型，避免使用NVARCHAR(MAX)等宽泛类型
参数类型越宽泛，攻击者可利用的空间越大。例如@name NVARCHAR(MAX)允许传入高达2GB的恶意负荷，后续校验极易被绕过甚至导致系统崩溃。
- 数字型参数应直接使用
INT、TINYINT，并在过程开头进行边界检查：IF @id < 1 OR @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)包裹（注意：QUOTENAME仅用于标识符，不可用于值）。 - 更安全的策略是采用白名单硬编码：
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或引发报错，而这一转换瞬间正是整个安全链条中最脆弱的节点。
