sql注入的破坏力取决于数据库账户权限：mysql中file+select、process+show databases等组合最危险；sql server中db_owner角色隐式拥有execute、alter、control等全部权限，等同于交出整把钥匙。
SQL注入本身不决定破坏力，权限才决定能干多大事
SQL注入只是给了攻击者“一张嘴”，但这张嘴能说出什么话、能命令谁干活，全看数据库账户手上有多少权限。一个只被授予SELECT权限的账号，就算被注入，最多只能读几张表；而如果账号有DROP TABLE、FILE或EXECUTE权限，攻击者就能删库、写Webshell、调用系统命令。
MySQL里哪些权限组合最危险？
常见高危权限不是单个存在，而是成组放大风险：
-
FILE权限 +SELECT：可配合SELECT ... INTO OUTFILE或LOAD DATA INFILE读取服务器任意文件（如/etc/passwd）或写入PHP木马 -
PROCESS+SHOW DATABASES：能列出所有数据库名、查information_schema.PROCESSLIST窥探其他连接的SQL语句 -
CREATE USER或GRANT OPTION：注入后直接创建新高权限账号，实现持久化控制 - 账号
host设为'%'且密码弱：可能被横向打到其他应用共用的数据库实例
SQL Server中db_owner角色等于交出整把钥匙
在SQL Server里，db_owner角色不只是“能改数据”，它隐式包含：EXECUTE任意存储过程、ALTER任意对象、CONTROL整个数据库——这意味着即使你没开xp_cmdshell，也能通过sp_OACreate或sp_addextendedproc重新启用它。更隐蔽的是，db_owner用户还能读写msdb库，拿到SQL Agent作业脚本，进而执行任意操作系统命令。
真正安全的做法是只给db_datareader和db_datawriter，连VIEW DEFINITION都得按需单独授权——否则INFORMATION_SCHEMA和sys.objects就全暴露了。
权限检查不能只靠“当时建的账号”
很多团队以为当年建了个低权限账号就一劳永逸，但实际运维中容易踩坑：
- 开发临时用
root账号跑迁移脚本，完事忘了切回应用账号 - DBA为方便调试，给应用账号加了
REPLICATION CLIENT，结果被用来读取binlog获取原始SQL - 不同环境共用同一套账号体系，测试库开了
FILE权限，上线同步时没关 - 用
SHOW GRANTS FOR CURRENT_USER()查到的权限，未必是连接时实际生效的——如果账号被SET ROLE动态切换过，得查SESSION_ROLES
权限不是静态快照，而是运行时状态。定期用SELECT * FROM mysql.user WHERE user = 'app_rw'核对max_questions、max_updates等资源限制项，比只看GRANT语句更接近真实风险面。
