用扫描工具查不出恶意 JS 脚本怎么办，看看 Cloudflare Page Shield 怎么处理的

很多电商站看起来运行正常，但其实底层可能正跑着恶意 JavaScript，偷偷抢走分销佣金、劫持搜索点击、篡改分析数据，或者在跟远程服务器对接指令。这种攻击最阴险的地方在于页面加载、商品显示和结账流程完全没问题，但浏览器已经在执行站长根本没授权的操作了。

这就是 Page Shield ML 模型要解决的盲区。在实际捕捉到的 4 组攻击操作（共 8 个 Payload）中，自动化检测的效率远高于传统的扫描工具。事后复盘发现，这 8 个 Payload 里有 7 个在 VirusTotal 上完全搜不到，而 URLScan 对这 8 个全部给出了“无恶意”的判定。

有个具体的例子：Lnkr 家族的某个特定 Payload 版本在 URLScan 上被索引了快两年半，直到 2024 年 1 月直接扫描时，它依然显示为 No classification。虽然 VirusTotal 现在把它标记为恶意，但由于公开历史没记录具体什么时候开始标记的，所以单纯依赖标签太慢了。Page Shield ML 是直接在零售商的实时流量中把这些字节给揪出来的。结论很明显：如果你等安全工具打标签才行动，基本就迟了，必须用能规模化解析 JS 本身的 ML 模型。

这些攻击手段非常狡猾，没有统一的签名或隐藏技巧。有的脚本会潜伏，只有当设备、国家、时间、来源页或浏览器状态完全匹配时才会激活；有的把无点击的分销请求藏在不可见的 iframe 里；还有的会拦截点击、压制监控，或者根据条件从远程服务器加载代码。这种脚本就是为了在正确的目标出现前保持安静，所以单次页面扫描根本没用，必须有持续的浏览器可见性。

Cloudflare 规模化检测和标记 JS 的具体链路是这样的：

一、使用 GNN（图神经网络）初筛
Page Shield 采用 GNN 来分析 JavaScript，它不把代码当成简单的文本块，而是将其视为一个图（Graph）。通过语法树连接代码符号，分析谁调用了谁，攻击者试图掩埋什么，以及哪个部分在向外发送数据。这种结构化的分析能让它在面对代码压缩（Minification）、重命名或部分混淆时，依然能识别出可疑模式，而不需要依赖已知的 URL 或字节签名。

二、利用 LLM 进行二次验证
被 GNN 标记为恶意的脚本其实非常少（在所有分析流量中占比低于 0.3%）。为了降低误报率，这些脚本会被发送到 Workers AI 上的一个轻量级大语言模型（LLM）进行实时“第二意见”审核。只有当 LLM corroborates（证实）GNN 的判断时，才会向客户发出警报。

三、使用 Teacher 模型集群深度分析
对于最复杂的脚本，Cloudflare 使用一个由前沿模型组成的集群（称为 Teachers），这是一个自动化评审组。这个集群包含了来自 6 个不同家族的领先模型（包括在 Workers AI 上运行的开源权重模型）。每个模型被部署为一个 Agent，在独立的会话中分析同一个可疑脚本，并利用受限的 JavaScript 执行工具进行实操分析。