装了防护不等于挡住了注入

见过不少站点，防护面板上规则全是绿的，日志里天天有拦截记录，可数据库里还是多出一堆不该存在的账号。翻回去看才发现，WAF 上线时先开着观察模式，管理员打算等业务平稳了再改成拦截，后来事情一忙就忘了改。也有另一种情况：防护只看了 URL 里的参数，而接口把查询条件全塞在 JSON 请求体里，注入语句从 body 进去，检测点却停在问号后面那一段。还有一种更隐蔽，主域名接了防护，但老的测试域名、临时 IP、内网直连地址都还活着，攻击者从没有防护的那个入口进来，自然什么都拦不住。

说到底，WAF 是一层过滤器，效果只取决于两件事：请求是不是都从它这里走，以及它看不看得懂请求里的内容。

一次注入请求被拦下来的过程

请求先到边缘节点，防护要把它拆开看：URL 参数、表单字段、JSON 与 XML 请求体、上传文件的文件名、Cookie、自定义请求头。拆开之后才轮到解码，这一步最容易被绕。攻击者把 union select 写成 URL 编码，再叠一层十六进制或者 Unicode 转换，如果规则只解码一次就去做匹配，特征字面量根本不会出现。所以正规的引擎要做多轮解码，对同一段内容按不同编码方式还原之后分别匹配。

解码完了才是判断。规则大致分三类：关键字和特殊字符组合这类语法特征，明显偏离正常输入的语义特征，以及针对特定组件老漏洞的精确指纹。命中之后也不是一律拒绝，常见的处置有三档——直接拦断并返回拦截页，要求通过人机校验再放行，以及放行但记录用于后续分析。

这里有个容易忽略的细节：拦截只是结果，原始请求必须完整留档。规则调优、事后追责、判断到底有没有数据被拖走，靠的都是这份原始请求。有的部署为了省性能只记命中规则的编号，真出事之后连攻击者用了什么参数都不知道。

XSS 的麻烦在存储型

注入攻击的目标是数据库，XSS 的目标是浏览器。反射型 XSS 的载荷跟着请求来，防护看到可疑的脚本片段就能拦；存储型要麻烦得多，恶意内容提交时可能只是一段看着正常的文本，入库时干干净净，直到某个页面把它渲染出来才变成能执行的脚本，这时候拦截点已经不在入口了。

所以对 XSS，WAF 更像一道兜底网。真正要修的是两处：输出时按上下文做编码，HTML 里、属性里、脚本里、URL 里的处理方式各不相同；再配合内容安全策略，把内联脚本和不可信来源掐掉。会话 Cookie 加上 HttpOnly，能让万一得手的脚本拿不到登录凭证，把损失压小。

规则上线之后的活

刚上线时建议先记录不拦截，把真实流量喂上一两周，看看哪些请求会被误判。误判的来源其实很集中：后台富文本编辑器会提交大段 HTML，报表模块的查询条件里天然带 select、where 这些词，文件名里可能出现引号和尖括号。处理办法不是整个地址放行，而是把白名单收到具体接口的具体参数上，范围越小越安全。

规则升级之后也要回头看一眼，确认新规则没有误伤订单、支付、登录这类关键接口。判断标准不只是拦截数量的变化，还要看业务指标有没有异常波动。

它防不住的那些事

越权、薅羊毛、支付金额被改这类业务逻辑问题，WAF 基本帮不上忙，因为请求在语法上完全合法。低频的慢速探测、定制化的零日利用也容易滑过去。所以合理的定位是把它放进纵深防御：代码侧用参数化查询和输出编码解决根因，数据库账号只给必需的库表权限，运维侧把日志收好、告警配好。这几层缺一层，另外几层就得替它兜着。