只要不用字符串拼接构造SQL且所有用户输入都走参数化查询，脱库在技术上就几乎不可能发生；真正导致脱库的是绕过参数化拼接元数据（如表名、字段名）或高权限账号执行INTO OUTFILE等危险操作。
只要不用字符串拼接构造 SQL，且所有用户输入都走参数化查询，脱库在技术上就几乎不可能发生。真正导致脱库的，从来不是“没防住某种注入变种”，而是绕过参数化、直接拼接 table_name 或 column_name 这类元数据，或者用高权限账号执行了 SELECT ... INTO OUTFILE、LOAD DATA INFILE 等危险操作。
必须禁用的高危 SQL 功能和权限
即使代码层做了参数化，数据库账号若拥有下列权限，攻击者一旦拿到任意一个可注入的点（比如 order by 后的字段名），仍可能触发文件读写或跨库查询，进而实现脱库：
- 禁用
FILE权限：防止SELECT ... INTO OUTFILE或LOAD_FILE()读取服务器文件（包括/etc/passwd、MySQL 配置、甚至其他数据库的表文件） - 禁用
PROCESS和SUPER权限：避免通过SHOW PROCESSLIST或变量篡改获取敏感信息 - 禁止账号跨库访问：应用账号只授予目标数据库的
SELECT、INSERT等必要权限，不给mysql系统库任何权限 - 关闭
local_infile：在 MySQL 配置中设local_infile=OFF，并确保客户端连接时未启用LOCAL INFILE
order by / group by / 表名/字段名不能参数化，怎么办
这类语法位置天然不支持 ? 或命名占位符，硬塞参数会报错：SQL syntax error near '?' 。强行拼接就是高危漏洞入口：
- 白名单校验是唯一可靠方式：例如排序字段只允许
['id', 'created_at', 'status']，收到order=xxx就查表映射，不在列表中直接拒掉 - 表名/字段名动态拼接前，必须用正则严格匹配字母+下划线+数字，且长度限制在 64 字节内（MySQL 标识符上限）
- 绝对不要用
mysql_real_escape_string()或addslashes()处理这类位置——它们对反引号、空格、括号完全无效
Node.js / Python / PHP 中容易被忽略的“伪安全”写法
这些写法看起来像参数化，实则仍是拼接，等同于裸奔：
-
connection.query('SELECT * FROM users WHERE id = ' + userId)—— 拼接整段，毫无防护 -
cursor.execute(f"SELECT * FROM {table_name} WHERE id = %s", (user_id,))—— Python f-string 先执行，{table_name}已经进 SQL 了 -
$sql = "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'";—— 即使后面用了mysqli_real_escape_string()，也晚了 -
knex('users').where('name', req.query.name).toString()—— 如果你把结果再拼进另一个 query，knex 的参数化就失效了
脱库的最后一道防线：网络与日志
参数化 + 权限收紧后，攻击者若还想批量导出数据，只能靠大量合法请求硬刷。这时需要主动干预：
- 数据库前置加 WAF 或代理层（如 ProxySQL），对单 IP 短时间内高频
SELECT ... LIMIT 10000类查询做限流 - 开启 MySQL 的
general_log或审计插件（如 MariaDB Audit Plugin），重点监控含INTO OUTFILE、UNION SELECT LOAD_FILE、超长IN子句的语句 - 应用层记录所有带分页参数的查询（如
offset=10000&limit=1000），超过阈值触发告警而非静默返回
最常被忽视的一点：脱库往往不是从 SQL 注入开始的，而是从一个本该 403 的后台接口、一个暴露了 phpinfo() 的调试页、或一个未授权访问的 /backup.sql 链接发起的。防护的重点，永远是“不让第一个恶意请求跑通”，而不是“让第 1000 个恶意请求慢一点”。
