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') 是否返回空——这些才是影响范围的实际边界。