浏览器端攻击为何会绕过扫描器
现代电商页面可能看起来一切正常：页面能打开，商品能展示，结账流程也能完成。但在浏览器里，恶意 JavaScript 可能正在悄悄执行未经授权的操作，例如窃取联盟营销佣金、劫持搜索和点击、篡改分析数据，或向远程服务器询问下一步该加载什么代码。
这类风险的难点在于：页面“能用”并不代表页面“安全”。一次性扫描、静态哈希匹配或已知恶意网址列表，往往无法覆盖那些按条件触发、短暂出现、或隐藏在营销标签链路中的脚本。
扫描器漏掉了什么
一组浏览器端安全检测案例中，机器学习系统在真实流量中发现了 4 组恶意 JavaScript 行动，涉及 8 个载荷。后续人工复核确认后，再用常见安全扫描工具回看：
- 8 个载荷中有 7 个当时并未出现在 VirusTotal 中；
- URLScan 对这些载荷均未给出恶意判定；
- 其中一个与 Lnkr 家族相关的具体脚本版本，曾在 URLScan 中以“无分类”状态存在近两年半；
- 即使某个哈希早已被收录，也不代表其背后的代码已被准确判定为恶意。
这说明：“看见文件”不等于“理解代码行为”。如果防御体系必须等到某个哈希、URL 或脚本被公开标记为恶意，往往已经滞后。
为什么这些脚本难以发现
这些行动并没有统一的签名，也没有完全相同的隐藏方式。它们的共同点是：都试图只在合适条件下行动，降低被自动化扫描发现的概率。
已观察到的行为包括：
- 在不可见 iframe 中发起无需点击的联盟请求；
- 拦截用户点击并改写跳转路径；
- 抑制监控或调试痕迹；
- 根据条件从远程服务器加载更多代码；
- 利用动态页面元素，在商品卡片或按钮出现后再绑定劫持逻辑。
因此，只抓取一次 HTML、打开页面看一眼，往往不够。很多恶意脚本会等待“合适的访客”出现：例如移动端用户、特定时间段的访问者，或真正点击商品按钮的人。
检测思路：把 JavaScript 当作行为图来分析
这类检测使用图神经网络分析 JavaScript，而不是把脚本当成一整块文本或单纯依赖关键词。模型会根据语法树和调用关系理解代码结构，例如：
- 哪些函数调用了哪些对象；
- 哪些逻辑被刻意隐藏或混淆；
- 是否存在可疑的远程通信；
- 是否存在点击劫持、支付窃取、挖矿或其他恶意行为迹象。
这种方式可以在一定程度上跨越压缩、变量重命名和部分混淆，不必完全依赖已知 URL 或字节级签名。
在该流程中，只有极少数脚本会被图神经网络标记为恶意，比例低于所有分析流量的 0.3%。这些脚本随后会交给轻量级大语言模型进行二次判断，以降低误报并保持召回率。对于复杂样本，还会使用多个前沿模型分别分析同一段脚本，并将不同模型的判断作为投票信号，最终辅助人工复核与后续模型训练。
案例一：下班时段的联盟佣金劫持
第一类行动针对电商联盟归因。
攻击流程可以概括为：
符合条件的移动端访客 → 点击商品 → 脚本拦截点击 → 新标签页打开攻击者预设页面 → 原标签页通过攻击者联盟链接绕行后回到店铺
对用户来说，店铺仍然可用，商品仍然能打开。但后台可能已经发生了归因劫持：如果用户之后完成购买，销售额可能被错误归因给并未真正带来访客的联盟账号。
商家可能损失什么
这类攻击不一定窃取银行卡，也不一定破坏页面。但它会影响商业归因：
- 商家可能向攻击者控制的账号支付并不应得的佣金；
- 如果原本是合法合作伙伴带来的流量，佣金可能被错误转走；
- 长期看，合作伙伴可能因归因不可信而降低对商家的信任。
它如何隐藏
研究中发现了 5 个相关脚本版本，其中 2 个活跃，3 个在捕获时处于暂停状态。活跃版本会设置多重触发条件，例如：
- 访问者设备类型；
- 本地时间；
- 该设备近期是否已经触发过；
- 商品按钮是否已经出现在页面上；
- 用户是否真的点击了目标按钮。
脚本还会使用 MutationObserver 监听页面中后续动态出现的商品卡片或按钮。许多电商页面会在初始 HTML 加载后再渲染商品内容，因此只抓取静态 HTML 的扫描器可能看不到真正的劫持路径。
在后期活跃变种中，脚本会在符合条件的点击发生后向 localStorage 写入约 3 天的冷却时间，让同一设备在数天内不再触发，以减少异常暴露。随后它执行“双标签页”操作：
- 在新标签页打开攻击者选择的商品或活动页，让用户继续浏览；
- 原标签页快速经过攻击者联盟追踪链接再返回店铺，以便种下攻击者的归因 Cookie。
部分脚本还包含控制台掩盖和自防御检查，使安全人员调试和查看源码变得更困难。
通过营销供应链投递
该行动借助了电商站点常见的第三方营销脚本和标签管理链路。一个已确认路径是：
Google Tag Manager → 另一个标签管理器 → 恶意脚本
这说明恶意载荷可以混入日常营销技术栈，但这并不等于上述标签管理器本身被攻破。
攻击者还使用了近似广告域名来降低人工审核时的可疑程度。例如，一个投递域名与一家早年注册的广告域名仅相差一个字母，并在页面上伪装成营销机构。这属于典型的域名仿冒手法，用来让恶意营销标签看起来更“正常”。
案例二：无需点击的联盟窃取
第二类行动甚至不需要用户点击广告。
用户只要打开某个预订页面，在商品选项附近停留，后台脚本就可能在满足条件时通过隐藏 iframe 发起联盟请求。这样一来，用户后续购买可能被错误归因为由某个第三方带来，即使该第三方并没有真正促成访问。
与第一类行动相比，这类攻击更隐蔽，因为它不一定需要可见跳转，也不一定伴随明显的页面变化。
对防守方的启示
这些案例的关键不在于某一种具体脚本，而在于攻击模式已经从“明显破坏页面”转向“悄悄操纵浏览器行为”。对电商和依赖前端脚本的业务而言，值得关注以下几点：
- 第三方脚本和标签管理链路应纳入安全监控；
- 仅依赖哈希、URL 黑名单或一次性扫描存在盲区；
- 应关注脚本运行时行为，包括点击拦截、隐藏 iframe、远程加载和本地存储冷却逻辑；
- 动态渲染页面需要持续观察浏览器端行为，而不是只分析初始 HTML；
- 对联盟营销、广告归因和分析数据的异常，应与前端脚本变更联动排查。
这些攻击未必都会直接窃取支付信息，但仍可能造成收入流失、归因污染和合作伙伴信任受损。对于现代店铺而言，浏览器端已经成为供应链安全的一部分。