waf和参数化查询在0day面前失效，因waf依赖已知特征易被注释/大小写/函数嵌套绕过，而“伪参数化”（如拼接表名、mybatis ${}）使结构可控；数据库须强制最小权限、禁用高危函数、启用查询白名单，并结合运行时sql行为监控实现纵深防御。
0day漏洞引发的SQL注入，无法靠补丁或规则库提前拦截——它出现时，你连CVE编号都没有。唯一能做的，是让攻击者即使拿到0day利用链，也难以真正执行恶意SQL、读取数据或破坏结构。
为什么WAF和参数化查询在0day面前会失效
WAF依赖已知特征（如UNION SELECT、' OR 1=1），而0day利用往往绕过这些模式：用注释符/**/拆分关键字、用大小写混写UnIoN、或借助函数嵌套（如CONCAT(CHAR(45),USER())）逃逸检测。参数化查询本身没问题，但若开发中存在“伪参数化”——比如用string.format()拼接表名或列名，再传入参数值——那0day仍可控制语句结构。
- 常见错误：ORM中用
.raw("SELECT * FROM " + user_table)动态指定表名 - 真实案例：某金融系统被利用MyBatis的
${}语法注入，绕过所有#{}参数化保护 - 关键点：
#{}安全，${}不安全；预编译只保护值，不保护标识符
数据库层必须启用的三项硬隔离措施
即便应用层被突破，数据库本身要成为最后一道闸门。这三项配置不能仅靠文档说明，必须在部署脚本里固化验证。
- 连接账户强制使用最小权限：Web应用账号禁止
DROP、ALTER、CREATE、EXECUTE，连SELECT也要按需限制到具体视图或字段级（如用GRANT SELECT (id, name) ON users TO app_reader） - 禁用高危函数：在MySQL中执行
SET GLOBAL log_bin_trust_function_creators = OFF，并移除LOAD_FILE、INTO OUTFILE、SLEEP等函数的执行权限 - 开启查询白名单（如MySQL 8.0+的
query_rewrite插件）：只允许预注册的SQL模板被执行，任何字段数、ORDER BY位置、子查询嵌套深度超出模板的请求直接拒绝
运行时SQL行为监控如何捕获异常模式
不是看有没有UNION，而是看“这个用户平时只查3个字段，今天突然查了27个”或者“这个接口历史平均响应时间12ms，现在持续卡在3s以上且返回行数为0”。这类信号比字符串匹配更可靠。
- 部署轻量级SQL审计代理（如Percona Query Analytics或开源的
pgAuditfor PostgreSQL），采集query duration、row count、parsed AST depth三类指标 - 对每个业务接口建立基线：例如登录接口正常应
SELECT 1 field FROM users WHERE email = ?，若某次请求AST中出现UNION节点或JOIN超过1层，立即熔断并告警 - 避免全量日志：只记录触发阈值的异常会话ID，后续通过
SHOW PROCESSLIST或pg_stat_activity反查原始SQL
纵深防御真正的复杂点不在技术选型，而在于权限与监控的“颗粒度”——表级权限不够，得压到字段；日志采样率设太高拖垮DB，设太低漏掉慢注入；WAF规则加太严误杀业务，加太松放行0day。这些平衡点没有标准答案，只能靠生产流量反复校准。
