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 权限、没有意外启用的外围组件——人容易忘,脚本不会。










