web应用防护系统

去年秋天，一个做跨境电商的护系朋友半夜给我打电话，说网站首页被挂了一串阿拉伯文，应用防点进去直接跳转到博彩页面。护系他用了某云的应用防WAF，规则全开，护系还是应用防被打穿了。攻击者没用什么0day，护系就是应用防找一个老旧的上传接口，传了个.php.jpg，护系绕过了后缀黑名单。应用防WAF日志里干干净净，护系因为流量走的应用防是正常HTTP，参数里没带任何特征。护系这事儿让我重新翻了一遍ModSecurity的应用防规则库，发现很多默认规则对文件内容检测几乎为零。

WAF这东西，说白了就是HTTP层的安检机。它不关心你服务器跑的是Java还是Go，只看请求长什么样。但安检机有盲区——它不知道你业务逻辑里哪个参数该是数字，哪个该是JSON。正则匹配能拦住union select，却拦不住1' || (select 1 from pg_sleep(5))--这种变种。我见过太多运维把WAF当银弹，装完就不管了，连个自定义规则都不写。

上面这段请求，很多WAF只看Content-Type是image/jpeg就放行了。文件内容里的PHP代码？不检查。文件名后缀是.php？有些WAF会拦，但改成.phtml或.php5就过了。我见过最离谱的，某商业WAF把php关键字放在文件名里就拦，结果攻击者用ph%70编码一下，照样上传。

真正有效的防护，得在WAF后面加一层文件内容检测。比如用libmagic判断真实MIME类型，再配合白名单——图片就只允许image/png、image/jpeg，其他一律拒绝。但这样会误杀，有些业务就是允许上传SVG。所以规则得动态调，不能一刀切。

另一个坑是性能。我测试过一台4核8G的机器跑ModSecurity，开OWASP CRS规则集，QPS从1200直接掉到300。CPU全耗在正则回溯上。后来换成基于语义分析的引擎——比如用libinjection检测SQL注入，比正则快一个数量级，而且误报率低。但语义分析也有短板，对业务逻辑漏洞基本无感。比如越权访问/user/123/profile改成/user/124/profile，WAF根本不知道123和124是不是同一个人。

所以现在我的做法是：WAF只拦已知的通用攻击——SQL注入、XSS、路径穿越、命令注入。业务逻辑漏洞交给代码层做权限校验。两层各司其职，别指望一个系统包打天下。另外，WAF的日志一定要接SIEM，单独看WAF日志没意义。有一次我发现某IP在十分钟内触发了200次modsecurity规则，但每次都是不同参数。拉出来一看，是在做参数模糊测试。这种低频慢速攻击，光靠WAF的阈值拦截根本拦不住。

最后说个反直觉的：很多WAF的learning mode（学习模式）其实是灾难。它会自动放行所有“正常”流量，但攻击者只要在前期发足够多的正常请求，就能把恶意payload“学习”成白名单。我见过一个案例，攻击者用两周时间每天发几千次带union select的请求，WAF学习后直接放行，最后拖库。所以别偷懒，规则得手动调，白名单得人工审。WAF是个好工具，但它不是保安，只是个门禁——门禁卡可以复制，保安会打瞌睡，你得自己盯着监控。