sql注入实际危害取决于注入后能走多远，核心由数据库权限、数据敏感性、系统连通性三点决定：高权限账户（如root、sa）可写webshell或执行系统命令；敏感字段（如password_hash、id_card）泄露直接触发合规风险；数据库暴露在公网或与内网系统互通则扩大横向渗透风险。
影响范围不是看“能不能注入”，而是看“注入后能走多远”——数据库权限、数据敏感性、系统连通性这三点，直接决定漏洞实际危害。
数据库账户权限决定了攻击者能干到什么程度
应用连接数据库用的账号，权限越小，风险越可控；一旦是 root、sa 或拥有 FILE 权限的账号，就极可能被用于写入 Webshell、读取服务器文件甚至执行系统命令。
- 检查方式：登录数据库后执行
SELECT CURRENT_USER()和SHOW GRANTS - 常见高危权限：
SELECT INTO OUTFILE（可写文件）、LOAD_FILE()（可读任意文件）、EXECUTE（可调存储过程） - MySQL 5.7+ 默认禁用
secure_file_priv，但若配置为''或/var/www/等可写路径，INTO OUTFILE就能落地 shell
敏感数据类型和存量直接量化泄露后果
不是所有表都一样危险。评估时必须区分字段内容，而非只看“有没有用户表”。
- 高影响字段：
password_hash、id_card、bank_account、api_key、refresh_token - 中影响字段：
email、phone、address（GDPR/《个人信息保护法》明确约束） - 低影响字段：
created_at、status（除非配合其他漏洞形成链式利用） - 别忽略日志类表：如
audit_log或admin_operation，可能暴露管理员行为或内部路径
网络拓扑与数据库部署方式放大横向风险
数据库是否仅对应用服务器开放？是否与内网其他系统共用认证？这些比“能否注入”更关键。
- 若数据库监听
0.0.0.0:3306且无防火墙限制，攻击者可能绕过应用，直连数据库 - 若使用云数据库（如 AWS RDS、阿里云 PolarDB），确认安全组是否允许非应用 IP 访问
- 若数据库与 Redis、Elasticsearch 同属一个 VPC，且凭据硬编码在配置里，盲注出的账号密码可能成为跳板
- 特别注意 Docker 场景：
host.docker.internal或network_mode: host可能让数据库暴露给容器网络之外
真正容易被忽略的点是：很多团队花大力气测出 id=1' and 1=1-- 能回显，就认定“存在 SQL 注入”，但没验证 UNION SELECT 是否被 WAF 拦截、SLEEP() 是否被超时机制截断、LOAD_FILE('/etc/passwd') 是否返回空——这些才是影响范围的实际边界。
