内容摘要：WAF这东西，说白了就是网站前面的一道安检门。你正常访问，它放行；你带着攻击载荷，它拦截。听起来挺美好，但现实里这道门有时候连自己人都打。 去年冬天我碰到过一次典型的WAF事件。客户是个做跨境电商的小

WAF这东西，说白了就是网站前面的一道安检门。你正常访问，它放行；你带着攻击载荷，它拦截。听起来挺美好，但现实里这道门有时候连自己人都打。

去年冬天我碰到过一次典型的WAF事件。客户是个做跨境电商的小团队，站点部署在云上，前面挂着一家知名厂商的云WAF。某天下午三点左右，运营在群里喊：后台登不上了。我第一反应是数据库挂了，结果SSH上去一看，服务全在，Nginx日志也正常。问题出在WAF那一层——它把所有带select字样的请求全拦了。巧的是，他们后台有个商品筛选功能，参数名就叫select_type。运营点一下筛选，WAF就判定这是SQL注入，直接返回403。

更离谱的是，拦截日志里连攻击类型都标得明明白白：SQL Injection。可那明明只是个普通查询参数。WAF的规则引擎把参数名当成了攻击特征，压根没看上下文。这种误杀在行业里太常见了，厂商管它叫“误报”，但对企业来说，这就是事故。

我联系了WAF厂商的技术支持。对方第一句话问的是：“你们是不是用了select这种敏感词做参数名？”我说是。他说：“那没办法，规则就是这样，你们改参数名吧。”我当时就火了——改参数名意味着前端后端一起动，测试回归全得重来，就为了迁就一个WAF的弱智规则？

后来我们查了那家WAF的规则库，发现它用的是正则匹配加关键词黑名单。这种方案便宜、快，但代价就是误杀率高。真正做得好的WAF会结合语义分析、机器学习模型，甚至给每个站点单独训练基线。可那玩意儿贵，小团队根本用不起。

事情最后怎么解决的？我们在WAF前面加了一层Nginx，把select_type这个参数重写成了stype。请求到了WAF那里，它一看没有敏感词，放行。后端再改回来。绕了一圈，问题没了，但我觉得挺荒诞的——为了绕过一个安全设备，我们得再写一层代理。

这件事让我对WAF的看法变了不少。以前我觉得WAF是标配，现在我觉得它更像一把双刃剑。规则太松，等于没开；规则太严，业务先死。很多厂商卖WAF的时候吹得天花乱坠，什么AI引擎、自学习、零误报，真上了生产环境，该拦的不拦，不该拦的乱拦。你去找他们，他们永远一句话：规则可以调，但调完出了事我们不负责。

还有个细节挺有意思。那次事件之后，我特意去看了几家云厂商的WAF文档。发现他们默认规则里，select、union、sleep这些词全是高危。可现实里，select是HTML标签名，union是TypeScript类型关键字，sleep是定时任务常用函数名。这些词出现在参数里再正常不过。WAF厂商不可能不知道，但他们选择一刀切，因为这样最省事。

所以我现在给客户的建议是：上WAF可以，但一定要开观察模式跑一周，把误报全捞出来，该加白名单加白名单，该改规则改规则。别一上来就拦截模式，否则你连怎么死的都不知道。安全这东西，从来不是买个设备就完事了，得有人盯着，得持续调。WAF事件说到底，不是技术问题，是人的问题——厂商图省事，运维图省心，最后业务买单。