SQL注入本身不直接拖库，但它是拖库最常用入口；拖库成败取决于注入点能力、数据库账号权限高低及敏感字段是否加密。
SQL注入本身不直接“拖库”，但它是拖库最常用的入口——只要能执行任意查询，SELECT 就能导出全表，UNION 就能跨表拼接，LOAD_FILE 或 INTO OUTFILE 甚至能读写文件系统。拖库是否成功，取决于注入点能走多远，而决定这条路能走多远的，正是数据库账号权限和敏感字段是否加密。
为什么低权限账号能大幅限制拖库范围
很多系统用一个高权限账号（如 root 或 sa）连接所有业务模块，一旦某个接口存在 SQL 注入，攻击者就能执行 DROP TABLE、SHOW DATABASES、CREATE PROCEDURE 等危险操作。权限隔离的核心是：每个业务模块只分配它真正需要的最小权限。
- 用户登录模块只需对
users表有SELECT权限，且仅限查id、username、password_hash字段（通过视图或列级权限控制） - 订单查询接口不应拥有对
payment_cards表的任何访问权，哪怕只读也不行 - 绝对禁止授予
FILE、PROCESS、SHUTDOWN、GRANT OPTION等高危权限 - MySQL 中可用
REVOKE FILE ON *.* FROM 'app_user'@'%'显式收回文件操作能力
加密存储对拖库的实际拦截效果
即使攻击者通过注入拿到了整张 users 表，如果 phone、email、id_card 等字段是加密存储的，且密钥未与应用代码混在一起（比如没硬编码在配置里），那么导出的数据就是一堆不可逆的密文。这时拖库就退化为“拖密文”，实际价值极低。
- 优先使用带盐哈希处理密码：
password_hash字段应存bcrypt或Argon2输出，而非明文或简单 MD5 - 敏感字段加密需分离密钥管理：密钥不应出现在数据库或 Web 服务器磁盘上，推荐用 KMS（如 AWS KMS、阿里云 KMS）或 Vault 动态获取
- 避免应用层自行实现加解密逻辑——容易因 IV 复用、ECB 模式、弱随机数等问题引入新漏洞
- 注意：MySQL 的
AES_ENCRYPT()函数若密钥写死在 SQL 里，等于把密钥和密文一起暴露给注入者
注入点存在时，权限+加密如何协同起作用
真实攻击链中，权限和加密不是二选一，而是分层卡口。例如一个注入点只能执行单条 SELECT，且数据库账号只有 SELECT 权限：
- 若字段未加密 → 攻击者执行
SELECT * FROM users即可拿到全部明文数据，完成拖库 - 若仅密码哈希化 → 其他字段（如手机号、地址）仍是明文，仍构成严重泄露
- 若所有敏感字段均加密 + 密钥由外部 KMS 托管 → 注入者最多拿到密文+空密钥，无法还原原始信息
- 若还配合行级权限（如 MySQL 8.0 的
ROW ACCESS POLICY）→ 连“哪些用户能被查到”都受策略约束，注入结果集可能为空
最常被忽略的一点是：加密不能替代权限控制，权限也不能替代加密。前者防“查得到”，后者防“看得懂”。两者缺一，拖库风险就仍在临界点上。
