网站挂马检测：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5e8011db8197.html
📄
网站挂马检测：访客被分配到不同版本时怎样识别样本污染
先给结论：如果同一时间、同一入口、同一类访客拿到的页面内容不一致，那么你手上任何一份样本都只能算“某个版本的表现”，不能直接当作整站被挂马的证据。识别样本污染的关键不是多抓几次，而是先固定“版本变量”，再判断差异来自服务端分组、缓存层还是检测工具本身。只要版本变量没有锁定，后续所有比对结论都会失效。
先确认版本差异是否真实存在，而不是抓取抖动
访客被分配到不同版本，通常有三种可区分的原因：服务端按条件返回不同内容、中间缓存或CDN保留了旧副本、检测工具自身带了会话或UA差异。三者证据不同，处理动作也不同。
- 服务端分组：同一IP、同一UA、连续多次请求，结果稳定地分成两类。这类差异可复现，属于真实版本分歧。
- 缓存层残留：第一次请求拿到旧内容，带随机参数或清缓存后拿到新内容，之后再请求又回到旧内容。差异不稳定，取决于命中哪个节点。
- 工具侧污染：换一个不共享Cookie、不共享出口IP的环境后，差异消失。这说明之前的“不同版本”是检测工具自己造成的。
把这三类分开，才能避免把缓存抖动误判为挂马，也避免把真实的分组注入当成工具噪音放过去。
锁定版本变量的实际操作
一个可执行的动作是：对同一URL，固定UA、固定出口IP、不带Cookie，连续请求若干次，并记录每次返回的正文哈希和关键片段。如果哈希稳定分成两组，说明服务端在按某种条件分流；如果哈希随机跳变，优先怀疑缓存或负载均衡节点不一致。
这个动作的结果会直接决定下一步：分组稳定时，下一步是找出分组条件（来源IP段、UA、Referer、登录态）；随机跳变时，下一步是绕过缓存层直连源站再测，而不是继续在边缘节点上比对。
一个注明假设的短例子
假设某站点有A、B两台源站，负载均衡未做会话保持。检测时请求十次，六次返回正常页，四次返回被注入的页。此时不能得出“四成访客被挂马”的结论，因为样本被两台源站污染了。正确做法是分别直连A和B各测若干次：若只有B返回注入内容，问题定位到单台机器；若两台都返回，才需要考虑共同的上游或部署流程。
什么情况会让上面的判断失效
有一个反例必须提前说明：如果分流条件本身与访客身份绑定，比如仅对特定地区、特定登录态或特定来源返回不同内容，那么“固定IP和UA连续请求”得到的稳定结果，反而可能只是同一分组的重复，无法暴露另一分组。
这种情况下，样本污染不是来自工具抖动，而是来自你的取样范围太窄。判断依据是：换一个明显不同的来源环境后，是否出现此前从未见过的版本。若出现，说明之前锁定的变量不足以覆盖全部分组，前面的结论需要推翻重来。
把结论落到下一步动作
识别样本污染之后，先不要急着清理。按版本分别保存证据：URL、请求条件、返回正文的关键差异片段、时间。然后判断哪个版本是“应当保留的部分”，哪个是需要退出的旧内容或旧系统残留。
如果差异只出现在旧合作关系遗留的接口或旧系统页面上，而主站版本一致，那么处理范围可以收窄到那部分旧资产，不必全站排查。反之，如果注入内容出现在多个分组共用的模板或公共资源里，收窄处理就会漏掉真正的入口。这一步的判断依据是差异片段是否落在共享组件上，而不是差异出现的次数多少。
最后提醒一点：第三方估算流量、搜索引擎报告和站内统计的口径本就不同，某一份样本归零或某次抓取异常，都不能单独证明处理正确。要确认清理是否生效，仍需在锁定版本变量的前提下重新取样比对。
