SQL Server账户不应拥有db_owner权限，应遵循最小权限原则：新建专用登录名和数据库用户，仅授予db_datareader与db_datawriter；动态SQL必须使用sp_executesql参数化；生产环境禁用sa直连、Integrated Security及危险配置项如xp_cmdshell。
SQL Server 账户不该有 db_owner 权限
绝大多数被注入攻破的数据库，根源不是没过滤输入，而是账户权限过大。一个 Web 应用只需要查商品、下订单，却给了 db_owner 角色——等于把保险柜钥匙和开锁工具一起塞给前台接待。
实操建议：
- 新建专用登录名（
CREATE LOGIN），禁用sa或其他高权限账户直连应用 - 为每个数据库创建独立用户（
CREATE USER），只授予db_datareader+db_datawriter（仅需读写） - 若必须执行存储过程，显式授予权限：
GRANT EXECUTE ON [usp_GetProduct] TO [web_user]，而非整个db_executor - 绝不在生产环境用 Windows 身份验证的管理员组（如
BUILTIN\Administrators）映射为数据库用户
动态 SQL 场景下必须用 sp_executesql + 参数化
很多“防注入”失败，是因为开发误以为拼接字符串加了单引号转义就安全。SQL Server 对 EXEC(@sql) 完全不校验参数来源，只要字符串能解析就执行——恶意输入早就在拼接时混进语句体了。
正确做法只有一条：所有运行时构造的 SQL，必须走 sp_executesql，且所有外部输入必须作为参数传入。
错误示例：EXEC('SELECT * FROM Users WHERE name = ''' + @input + '''')
正确示例：EXEC sp_executesql N'SELECT * FROM Users WHERE name = @name', N'@name NVARCHAR(50)', @name = @input
注意：sp_executesql 的参数定义（第二参数）必须显式声明类型和长度，不能写 @name SQL_VARIANT 或省略长度，否则可能触发隐式转换绕过检查。
连接字符串里别留 sa 密码，也别用 Integrated Security=true
本地开发用 Windows 身份验证很省事，但部署到服务器后，Integrated Security=true 实际是把 IIS 应用池身份（常为 ApplicationPoolIdentity）直接扔进数据库——这个账户一旦被提权，后果比泄露密码还严重。
更糟的是硬编码 sa 密码在连接字符串里，哪怕加密了，只要能读 web.config 或 appsettings.json，密钥往往也能被逆向出来。
安全底线：
- 生产环境连接字符串一律使用 SQL Server 身份验证，账号单独建、权限最小化
- 密码通过 Azure Key Vault / Windows DPAPI / Linux secret store 管理，绝不落盘明文
- 如果必须用 Windows 身份，确保应用池运行在专用域账户下，且该账户在 SQL Server 中只映射为受限数据库用户（非
sysadmin）
SQL Server 配置层面关掉危险选项
有些攻击不靠注入 SQL，而是利用 SQL Server 自带功能做跳板，比如启用 xp_cmdshell 后，一条注入就能直接执行系统命令；或开启 Ad Hoc Distributed Queries，让攻击者通过 OPENROWSET 连到内网其他数据库。
这些功能默认关闭，但运维过程中可能被临时打开并忘记关。
检查与关闭命令：
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 0; RECONFIGURE; EXEC sp_configure 'Ad Hoc Distributed Queries', 0; RECONFIGURE;
另外，tempdb 权限也要盯紧：禁止普通用户在 tempdb 创建永久对象（如全局临时表 ##t 可被跨会话访问），可通过拒绝 CREATE TABLE 权限实现。
真正难的不是知道要关什么，而是每次上线前跑一遍权限审计脚本，确认没有新增的 sysadmin 成员、没有新授的 CONTROL SERVER 权限、没有意外启用的外围组件——人容易忘，脚本不会。
