安全修复如何悄悄改变搜索引擎索引效果

　　去年七月那会儿，我原以为安全修复就是改改SQL注入、补补XSS漏洞，结果这玩意儿直接把搜索引擎的索引效果给搅和了——说白了，优胜劣汰的逻辑在这儿被玩出了新花样。那天下午三点，工单系统突然弹了条消息，说某核心页面的搜索流量掉了三成，我第一反应是：“又他娘的缓存炸了？”结果运维查了半天，缓存命中率挺高，QPS也没掉，倒是我写的那个安全中间件，日志里全是“403 Forbidden”。

文章配图，仅供参考

　　我盯着日志看了半天，发现被拦截的请求里，有三分之一是搜索引擎的。运维在旁边冷笑：“你当初不是说‘安全修复不影响业务’吗？”我怼回去：“我哪知道搜索引擎爬虫这么懒，这么多年都不换User-Agent！”他敲了敲键盘，说：“其实更坑的是，有些合法用户用代理工具，User-Agent也被误杀了——比如那个谁，昨天投诉说登录页面加载不出来，结果是因为他用了‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36’这种通用标识，被安全规则当爬虫处理了。”

　　咖啡凉了，我喝了口，苦得皱眉。这时候前端小妹凑过来，说：“我原以为安全修复就是改改后端代码，结果前端也受影响——我们有个页面用了第三方库，那库的请求头里带了‘curl/7.68.0’，也被拦了，现在页面部分功能加载失败。”我叹了口气：“这锅我背了，但安全团队也没提前说啊，他们只说‘要防爬虫’，没说具体怎么防。”

　　其实最坑的是，搜索引擎的反应比我想的慢。流量掉的那天，我们紧急把User-Agent黑名单改成了白名单，只放行已知的搜索引擎爬虫，但索引恢复需要时间——有些页面被拦截后，搜索引擎可能隔几天才重试，这期间用户搜不到内容，转化率直接掉。产品经理在群里骂：“你们搞安全修复，怎么不先灰度？现在老板问责，谁背？”我盯着屏幕，心想：“灰度？安全修复灰度个屁，要么全开，要么全关，哪有中间状态？”

　　后来我们查了数据，发现被拦截的请求里，有百分之二十是合法的搜索引擎爬虫，剩下的八成里，一半是爬虫，一半是用户误用代理。安全团队说：“这不能怪我们，规则是按行业标准写的。”我怼：“行业标准？行业标准里没写要拦‘Googlebot/2.1’啊！”他们沉默了一会儿，说：“那我们改规则，把主流搜索引擎的User-Agent加到白名单里。”我说：“行，但下次能不能先通知我们？我们好提前准备。”

　　窗外天黑了，我揉了揉眼睛，突然想起个事儿：去年招的新人，写了个SQL注入防护的中间件，结果把所有带“select”的请求都拦了——包括用户正常查询数据的请求。当时我们花了两天才定位到问题，最后发现是他把规则写得太死，没区分大小写，也没排除合法场景。现在想想，这和安全修复影响搜索引擎索引，其实是一个路数：都是“宁可错杀一千，不可放过一个”的逻辑，结果把自己坑了。

　　手机亮了一下，是安全团队的消息：“白名单规则已更新，请检查。”我回了个“收到”，然后去查日志——果然，拦截请求的数量降了，但搜索引擎的索引恢复没？没细看。运维说：“至少流量没继续掉，算不错了。”我点点头，心想：“这算哪门子不错？安全修复本来是为了防坏人，结果把好人也防了，这逻辑通吗？”

　　其实我现在也不确定，这种“优胜劣汰”的逻辑到底对不对——搜索引擎的爬虫该不该被严格限制？合法的用户代理该不该被误杀？安全团队说“安全第一”，产品说“用户体验第一”，我们夹在中间，只能改代码。下次再遇到这种事，我可能还是会吐槽，但至少知道该怎么查日志、怎么调规则了——至于能不能彻底解决，谁知道呢？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!