Cloudflare Client-Side Security 发现了公共扫描器遗漏的八个载荷

尽管公共扫描服务几乎没有发出警告，Cloudflare Client-Side Security 仍在四起店面攻击活动中发现了八个恶意载荷。受影响的页面依然能够加载、展示商品并处理客户交互。在这些看似正常的体验背后，JavaScript 会重定向联盟营销归因、隐藏网络请求、干扰分析工具，并建立远程代码执行通道。

Cloudflare 于 2026 年 9 月 16 日披露了这些发现。其核心观点挑战了一个常见的安全假设：扫描结果干净，并不意味着浏览器会话的行为就是安全的。Cloudflare 审查时，其中七个载荷尚未出现在 VirusTotal 中，而 urlscan.io 对全部八个载荷均未给出恶意判定。

这一对比很重要，但需要结合背景理解。VirusTotal 和 urlscan.io 基于提交的文件、URL、检测引擎和可观察行为提供有价值的情报。Cloudflare 则是在实时网站流量中发现这些脚本，并分析其内部结构。双方结论的差异暴露出一次性检查工件与持续观察代码进入真实浏览器之间的覆盖缺口。

四起攻击活动将正常的店面流量转化为针对商家的武器

Cloudflare 的发现之所以重要，是因为这些攻击活动无需破坏结账流程或让网站下线，也能直接攻击营收运营。

该公司的四起攻击活动发现涉及联盟营销盗用、点击操纵、远程代码加载、分析干扰和访客追踪。Cloudflare 表示，其自动化系统在人工分析师展开调查之前便发现了这些载荷。

第一起活动在特定时段针对移动端购物者。它会等待符合条件的商品元素出现，拦截购物者的点击，并在另一个标签页中打开攻击者选定的页面。与此同时，原始标签页会先经过一条联盟营销追踪路径，再返回商店。

这一绕行可能将归因分配给从未引荐该客户的联盟伙伴。商家随后可能支付不应得的佣金，或拒绝向合法合作伙伴记功。由于店面仍可正常运作，客户可能完全不会察觉。

Cloudflare 在该活动中发现了五个相关版本。其中两个在捕获时处于活跃状态，另外三个则被暂停。活跃变体会检查设备类型、本地时间、浏览器状态、商品可用性和近期执行记录，之后才执行任何可见操作。

后续版本会在浏览器的 localStorage 中保存一个为期三天的冷却期；localStorage 是网站脚本可使用的持久化存储区域。一旦被激活，恶意软件会在该设备上静默数日。因此，重复进行同样访问的扫描器可能看不到任何异常。

第二起活动甚至不需要购物者点击。其脚本会通过一个屏外 iframe 发起联盟营销请求；iframe 是嵌入页面布局之外、对用户不可见的页面。当主要方法失败时，一个隐藏链接可以自行触发点击。

该代码首先联系 IP 地理定位服务，但忽略返回的地理数据。如果该请求失败，恶意软件便会停止。Cloudflare 无法确定这一行为是有意规避沙箱检测，还是遗留逻辑所致。

第三起活动的范围更广。直接嵌入商家 HTML 的脚本包含较旧的搜索劫持模块，以及仍在运行的遥测和远程加载功能。页面加载后，它能够从攻击者控制的服务器请求新的 JavaScript。

这构成了店面后门。初始脚本无需包含最终动作，因为远程服务器可以改变其响应。Cloudflare 无法确定攻击者实际投递了哪些第二阶段载荷。

第四起活动瞄准通过付费营销活动进入网站的移动端访客。它尝试禁用九种分析或监测工具、压制客户支持界面、替换广告身份标识并传输遥测数据。

该脚本会检查视口宽度是否小于 477 像素，也会在访客前两次页面加载期间检查特定的营销活动标签。一份包含 325 项的 IP 子字符串列表帮助它规避与分析师或自动化基础设施相关的网络。

这些活动并不共享同一个域名、特征签名或变现策略。它们的共同特征是选择性执行。每个脚本都会等待短暂自动化检查不太可能复现的浏览器状态。

为什么一次干净扫描远远不够

核心冲突在于持续的浏览器可见性与时间点扫描之间，而不是机器学习与所有既有安全控制措施之间的对立。

传统扫描器能回答有用但有限的问题：是否有人曾提交过这个文件？检测引擎是否识别其特征签名？受控访问是否触发可观察的行为？当恶意软件自行决定哪些访客能看到真实逻辑时，这些问题的可靠性就会下降。

Cloudflare 的一个案例据称已在 urlscan.io 中被收录近两年半，却始终没有分类结果。其更广泛的恶意软件家族早已被记录，但这个特定载荷并未获得同样可操作的标签。

静态爬虫可以加载页面、检查文件并记录网络流量。然而，结果只代表某一时刻的某一种浏览器配置。店面恶意软件可能在激活前测试时间、设备、位置、引荐来源、Cookie、屏幕宽度和会话历史。

这类下班后联盟营销劫持程序会监视初始页面加载后创建的商品卡片。它使用 MutationObserver，这是一种能够检测页面文档结构变化的浏览器接口。若爬虫只捕获原始 HTML，就可能错过被挂钩的元素。

面向付费移动流量的伪装程序则更进一步。它会排除企业网络、云服务商、托管设施、VPN、代理、Tor 出口节点以及多个地理位置。这些检查会不成比例地排除研究人员和自动化扫描器常用的环境。

这带来一种令人不安的反转：来自企业网络的干净桌面测试，可能恰恰证明规避逻辑正在生效。商家看到的是正常分析数据，因为恶意分支从未在调查者的环境中运行。

这些攻击活动也说明，网站的运营健康状况可能具有误导性。可用性监控只能确认页面能够响应；合成结账测试只能确认交易可以完成。两者都未必能揭示归因最终给了谁，或浏览器发起了哪些连接。

服务器端日志提供的同样只是局部视角。第三方脚本可以访问页面文档和浏览器上下文。OWASP 的第三方脚本风险包括失去变更控制、任意代码执行以及敏感数据泄露。

Cloudflare 的证据并不意味着公共扫描器已经过时。提交的工件、历史观测、信誉数据和共享指标对于调查仍然不可或缺。这些发现表明，这类系统无法标记自己从未接收到的代码，或从未成功触发的行为。

最强的防御姿态是结合多种视角。信誉服务可以识别已知基础设施；代码分析可以审查意图；浏览器遥测可以暴露已加载资源和连接；人工分析师随后可判断自动化结论是否符合运营环境。

这种分层模型对仍将一次性扫描视为最终放行依据的安全团队构成压力。它同样对营销和电商团队构成压力，因为其标签管理器往往控制着安全团队极少持续审查的代码。

Cloudflare Client-Side Security 如何分析规避检测的 JavaScript

Cloudflare Client-Side Security 首先聚焦代码结构，随后使用语言模型和人工审查来缩小不确定发现的范围。

Cloudflare 的前线分类器是图神经网络，即 GNN。这种机器学习模型处理相互连接元素之间的关系。在这里，这些元素来自 JavaScript 的抽象语法树；它将代码表示为结构化操作，而非原始文本。

这种区别有助于模型忽略表面变化。攻击者可以重命名变量、压缩文件、轮换字符串或添加未使用的分支。这些变化会改变可见文本，却可能保留调用、条件、页面事件和网络请求之间的关系。

Cloudflare 表示，其 GNN 在实时流量中标记了全部八个载荷。该公司此前将更广泛的检测架构描述为级联流程，而非由单一模型做出所有决策。

GNN 被调校为捕获可疑结构。它认为无害的脚本会较早退出流程；潜在恶意脚本则会接受通过 Workers AI 运行的小型语言模型的二次评估。

第二阶段旨在解决误报问题。合法的广告包、机器人挑战、追踪脚本和压缩框架都可能看起来像恶意代码。它们可能使用混淆、动态执行、异常网络调用或其他脱离上下文便显得可疑的模式。

Cloudflare 在早期产品更新中称，其系统每天评估 35 亿个脚本。该公司还表示，平均每个企业区域会暴露约 2,200 个独特脚本。据其统计，其中约三分之一可在 30 天内发生变化。

这些数据来自 Cloudflare，尚未针对本次攻击活动披露接受独立审计。不过，它们仍说明了运营层面的挑战。即使误报率很低，在数十亿次评估中也会变得难以管理。

在最新调查中，Cloudflare 表示，进入语言模型审查阶段的分析流量不到 0.3%。如果该模型印证了 GNN 的判断，系统就会向客户发出警报。

更复杂的样本会接受另一层分析。Cloudflare 将约六个模型家族的模型作为相互独立的“教师”。每个模型都在全新会话中检查同一脚本，并可访问受限的 JavaScript 评估器。

这些模型会在四个标签中投票：无害、支付卡信息窃取、其他恶意软件和加密货币挖矿。Cloudflare 根据外部模型性能排名对投票加权。人工审查人员会检查被标为恶意，或未获得三分之二多数支持的脚本。

这并非完全自主的闭环。Cloudflare 承认，反馈至 GNN 训练的过程仍部分依赖人工操作。该公司还计划加入 Cloudflare Sandbox，以便在隔离环境中进行更深入的分析。

该方法结合了结构分类、语义审查、模型分歧和分析师判断。其优势不在于语言模型能够以某种方式“理解”每一种攻击，而在于每个阶段都针对不同的失效模式。

GNN 可以在高流量规模下识别结构相似性。语言模型可以过滤看似异常但合法的 JavaScript。多个教师模型可以揭示不确定性。分析师则可以调查自动化信号仍然令人担忧或存在分歧的较小样本集。

持续监控为这些判断提供了背景信息。Cloudflare 的安全文档称，该服务会观察访客加载的脚本、连接和 Cookie。高级功能还包括恶意脚本检测、代码变更告警和内容安全规则。

这种架构直接服务于核心竞争。即时工具只能检查选定的样本或会话。持续的浏览器报告会记录资源在真实访问中的出现方式，从而提高选择性恶意软件最终暴露的可能性。

浏览器已成为营收体系的一部分

这些攻击表明，客户端安全如今不仅保护支付数据，也保护归因、分析和客户访问。

前两起活动瞄准的是联盟营销经济，而非银行卡号。这一区别至关重要，因为许多店铺安全计划将最强的控制措施集中在结账环节。收入仍可能在客户旅程的更早阶段流失。

联盟系统决定哪位合作伙伴获得购买归属。攻击者无需中断交易，只要能够改变这一判定即可。一次欺诈性的归因请求，就可能将一笔合法销售转化为不应得的佣金。

首起活动的双标签页操作保留了客户的购物流程。一个标签页让访客继续参与，另一个则经过攻击者的追踪路径。攻击之所以获益，是因为它看起来像一次正常的导航事件。

无点击变体则更加隐蔽。一个不可见的 iframe 可以在无需客户实质互动的情况下发起联盟请求。Cloudflare 确认了这些自动化请求，但未能确定它们是否产生了已支付的佣金。

这一限制应当保持明确。代码能够证明意图和能力，却无法证明实际发生的财务损失。要衡量真实损失，还需要商户归因记录、联盟账户数据和付款历史。

付费移动端伪装器瞄准了另一项业务资产：可观测性。它聚焦于商户已通过付费搜索、文字广告活动及其他带标签渠道购买的流量。这些会话之所以有价值，恰恰是因为获客支出将它们带到了店铺。

该恶意软件试图替换分析标识符，同时禁用监控和支持工具。若成功，这可能会破坏广告活动报告，并使合法流量看似归属于其他来源。

它还会抑制聊天和联系控件。发现异常的购物者可能失去最便捷的报告渠道。商户随后将同时失去遥测数据和直接的客户反馈。

Cloudflare 的沙箱测试确认，替换后的分析脚本被加载并触发了追踪信标。不过，该公司未能证明攻击者获取了可用遥测数据，或转移了广告收入。

店铺后门带来了不同的风险。一旦脚本能够加载任意远程 JavaScript，攻击者的选择就不再局限于已观察到的模块。未来指令无需再次编辑商户 HTML 即可改变。

这种灵活性使事件范围界定更加复杂。移除一个可见的重定向，并不能证明攻击者没有其他能力。响应人员必须识别初始植入路径、远程端点、受影响会话，以及任何管理权限遭入侵的情况。

Cloudflare 无法确定该脚本如何进入商户的 HTML。它将失陷凭证、未经授权的模板变更，以及受感染的主题或插件列为可能路径，而非已确认原因。

这种不确定性对修复至关重要。封锁已观察到的域名可以阻止一条投递路径，却可能让原始访问路径继续开放。持久的应对措施需要凭证审查、模板完整性检查、依赖项清单，以及对标签管理器权限的检查。

业界已将浏览器视为支付安全边界的一部分。PCI Security Standards Council 的支付页面指南侧重于授权脚本、验证完整性，以及监控页面是否发生未经授权的变更。

Cloudflare 的这些活动扩展了开展这项工作的运营理由。浏览器不只是渲染结账表单。它还分配营销归属、记录行为、加载支持工具，并决定哪些外部服务接收客户数据。

因此，安全、营销、商务和分析团队共享同一攻击面。获准用于测量的营销标签可能成为投递路径。遭入侵的主题可能成为命令通道。归因机制可能成为窃取目标。

这种重叠带来了组织层面的压力。安全团队需要了解浏览器端变更，而营销团队则需要一种不会冻结每项活动的审查流程。困难在于，如何治理快速变化的脚本，同时不让正常的店铺运营难以为继。

Cloudflare 的发现仍需谨慎解读

活动证据支持持续监控，但并未独立验证每一项产品主张，也未量化商户的最终损失。

Cloudflare 发现了这些样本、运营了检测系统，并发布了技术分析。这使该公司能够直接获取有价值的遥测数据。但这也意味着，核心性能比较来自销售高级检测服务的供应商。

披露内容列出了八个载荷并说明其行为，但未公开受影响商户的身份。这一决定保护了受害者，也避免产生新的攻击目标清单。不过，它同样限制了对事件财务和运营后果的独立验证。

Cloudflare 没有发布在相同条件下，将其系统与所有扫描器进行比较的受控基准测试。其证据表明，VirusTotal 未收录其中七个载荷，而 urlscan.io 未给出恶意判定。这比证明其在整个市场中具有更优检测能力的结论要狭窄得多。

收录与分类也并不相同。服务无法标记从未收到过的文件。Cloudflare 能够观察这些脚本，是因为受影响流量经过了其网络和浏览器报告工作流。这种访问优势不同于模型准确率。

VirusTotal 已知的那一个载荷，进一步让简单的胜负叙事变得复杂。公开历史未显示恶意判定何时出现。因此，现有记录无法确定哪个系统最先识别出它。

误报值得关注，漏报同样如此。一个过度激进地标记陌生 JavaScript 的系统，可能压垮分析人员，或阻断合法商业活动。Cloudflare 部分使用额外的语言模型，是因为良性代码在结构上往往与恶意软件相似。

Cloudflare 此前报告称，在加入第二阶段后，误报大幅减少。这些结果来自内部评估，并非独立的同行评审评估。客户应根据自身脚本群体和事件结果来判断告警质量。

模型管线中也包含人为选择。决策阈值决定哪些脚本进入下一阶段。提示词塑造语言模型的审查方式。模型排序权重影响教师模型的投票。人工分析师裁决部分案例，并将标签反馈到训练中。

这些选择并不会使发现失效。它们说明了为什么“AI 检测到了它”并不是完整解释。检测质量取决于遥测、模型设计、阈值、分析师审查，以及告警后的响应流程。

内容安全策略，即 CSP，仍是另一项重要防线。CSP 告诉浏览器页面应允许哪些资源和连接。如 CSP 报告参考资料所述，其仅报告模式可在实施前收集违规情况。

然而，仅靠报告并不能阻止恶意代码。过于宽泛的允许列表可能放行已遭入侵的供应商。来自已受信任源的直接植入，也可能绕过简单的域名限制。

严格实施也会带来自身的运营成本。现代店铺会加载广告、实验、支付、个性化、支持和分析服务。它们的域名和代码可能频繁变化，使严格策略更难维护。

子资源完整性可以验证远程加载的文件是否与已批准的哈希值一致。它最适用于稳定资源。当供应商有意变更脚本，却不发布固定的版本化文件时，实施起来会更加困难。

实际结论并非某一项控制措施可以取代所有其他措施。持续观察、脚本清单、完整性检查、CSP、信誉情报和事件响应各自覆盖不同的缺口。

Cloudflare 最有力的证据涉及其自身遥测中发现的选择性恶意软件。尚未证实的领域包括实际收入失窃、第二阶段活动、初始访问，以及针对未观察攻击的性能。这些边界应影响任何采购或部署决策。

三项信号将表明持续检测是否奏效

下一项考验是，Cloudflare 能否将这些发现转化为可重复的检测、更清晰的证据和更快的商户响应。

第一项信号是更广泛的技术验证。安全研究人员可以利用已发布的指标，在其他环境中搜索相关基础设施和代码。更多发现将表明，这四项行动究竟是孤立的入侵，还是更大规模活动的一部分。

独立分析还可以确认脚本的归因行为、远程加载路径和反分析门槛。如果研究人员复现这些发现，Cloudflare 的解读将更具说服力。如果他们发现良性解释或不同结果，信心则应收窄。

第二项信号是 Cloudflare 扩展沙箱工作流后的检测质量。隔离的浏览器执行可以在保护生产系统的同时，为载荷行为提供更强证据。它还可以揭示哪些模型怀疑会在运行时测试中落空。

有用的报告应包括告警准确率、分析师确认的攻击、覆盖判定和漏报案例。汇总数据应区分已分析流量与唯一脚本，因为重复执行可能扭曲性能测量。

客户应关注解释质量，而不只是告警总数。一个有用的警告应指出触发的代码路径、观察到的连接、受影响页面和相关浏览器状态。笼统的恶意标签只会制造工作量，却无法指导遏制措施。

第三项信号是商户响应时间。如果技术上正确的告警无人查看、缺乏责任归属，或无法触发协调调查，其价值就很有限。店铺团队需要一条从浏览器证据到遏制措施的路径。

该流程应明确谁能够禁用标签、撤销凭证、恢复模板、封锁端点，并在事后验证分析数据。它还应保留用于判定佣金、客户数据或广告活动测量是否受影响的证据。

当持续监控缩短从首次恶意执行到成功移除之间的时间间隔时，它会更具说服力。如果团队收到告警，却无法区分真实入侵与例行脚本变更，它的说服力就会下降。

店铺所有者应直接提出一个问题：他们当前的控制措施能否说明哪些 JavaScript 到达了真实客户、这些代码做了什么，以及它连接到了哪里？一次干净的扫描无法回答这三个问题。

Cloudflare Client-Side Security 为获得这类可见性提供了一种方案，并有技术细节充分的厂商披露作为支撑。这些证据值得关注，但买方仍应在自己的线上店面中测试告警质量和响应集成能力。

眼下应采取的行动不应仅限于采购产品。应盘点浏览器脚本，审查标签管理器的权限，测试报告策略，并明确客户端告警的责任归属。随后衡量这些控制措施是否能够发现常规可用性和漏洞扫描无法察觉的行为。