SQL Server 2022本身不自动防御SQL注入，真正起效的是参数化查询、最小权限控制、错误信息脱敏、白名单校验表名列名、禁用xp_cmdshell及启用审计等主动配置措施。
SQL Server 2022 本身不“防御”SQL注入——它不会自动拦截或重写你拼接的恶意 SQL。真正起作用的是你是否启用并正确使用它的安全机制，比如参数化查询支持、执行上下文控制、权限隔离和错误信息屏蔽。用错配置，再新的版本也照常被绕过。
必须关闭 SHOWPLAN 和详细错误信息
SQL Server 默认在开发环境可能返回带表结构、列名甚至查询计划的错误（如 Msg 102, Level 15, State 1, Line 1: Incorrect syntax near '...'），这类响应是报错注入的温床。
- 生产环境务必设置
SET ANSI_WARNINGS OFF并禁用SHOWPLAN_ALL/SHOWPLAN_XML权限 - 在 SQL Server 配置中关闭
user options → show advanced options → showplan - 应用层统一捕获
SqlException，只返回泛化提示（如“请求处理失败”），绝不能透出Column 'xxx' does not exist这类信息
用 sp_executesql 替代 EXEC，且必须传参
动态 SQL 在所难免时，sp_executesql 是唯一安全的选择——但它只有在**所有用户输入都作为参数传入**时才真正有效。直接拼接变量名或表名仍会中招。
- ✅ 正确：
EXEC sp_executesql N'SELECT * FROM Users WHERE name = @name', N'@name NVARCHAR(50)', @name = @input - ❌ 危险：
DECLARE @sql NVARCHAR(MAX) = 'SELECT * FROM ' + @table_name + ' WHERE id = ' + @id; EXEC(@sql)—— 即使@table_name来自白名单校验，@id未参数化也会崩 - 注意：表名/列名等对象名无法参数化，必须走严格白名单校验（如
IF @table_name NOT IN ('Users','Orders') THROW 50000, 'Invalid table', 1）
限制数据库用户权限到最小必要集
SQL Server 2022 支持细粒度权限控制，但默认安装的 db_owner 或 sysadmin 账号一旦被注入利用，等于直接送钥匙。
- Web 应用连接字符串里的账号，应仅授予
SELECT/INSERT/UPDATE（按需）在指定表上，禁止EXECUTE任意存储过程、禁止VIEW DEFINITION、禁止访问sys视图 - 禁用
xp_cmdshell（即使没显式调用，堆叠注入可能触发）：EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; - 对敏感操作（如密码重置）强制走签名存储过程，并用
EXECUTE AS OWNER限定上下文，避免依赖调用者权限
启用SQL Server Audit并监控异常模式
审计日志本身不防注入，但能让你在攻击发生时快速定位来源——比如连续出现含 UNION SELECT、WAITFOR DELAY 或高频 master..sysdatabases 查询的会话。
- 启用服务器级审计，捕获
FAILED_LOGIN_GROUP和SCHEMA_OBJECT_ACCESS_GROUP事件 - 用
sys.fn_get_audit_file()定期扫描，过滤出含单引号+空格+关键词（OR、AND、--）的statement字段 - 注意：审计不替代编码防护，只是最后一道“看见”的防线；若已发生堆叠注入，攻击者可能已删日志表
最易被忽略的一点：SQL Server 2022 的新特性（如 APPROX_COUNT_DISTINCT 或内存优化表）本身不增强注入防护，反而可能因开发者误用动态 SQL + 新函数组合，引入更隐蔽的解析歧义。安全不来自版本号，而来自每一行 sp_executesql 是否真的用了参数、每一个连接字符串是否绑定了最小权限账号、每一次错误响应是否剥离了所有元数据。
