运行时检测 DOM 注入：为何静态防御失效
Source: Dev.to
现代 Web 应用程序与客户端注入
现代 Web 应用程序在很大程度上依赖客户端逻辑。框架、第三方 SDK、分析工具、A/B 测试库——所有这些都会动态操作 DOM。
正是这种灵活性悄然将浏览器变成了最难防御的场所之一。
DOM 注入不再表现为明显的 <script> 标签或恶意负载。如今，它们常常动态组装、条件激活，并融入合法的执行路径——远超传统安全工具的检测范围。
为什么客户端注入越来越难以捕获
DOM 注入与服务器端攻击在关键方面不同：
- 完全在用户的浏览器中执行。
- 没有畸形请求。
- 没有可疑的端点。
- 没有服务器日志。
多个因素使检测尤其困难。
应用复杂性
大多数现代站点从多个来源加载数十个脚本。这会产生一个庞大且不断变化的执行面，恶意逻辑可以隐藏在依赖项或注入的片段中。基于签名的检测在这里表现不佳——代码可能从未以静态形式出现。
动态和条件执行
攻击者不再注入完整脚本，而是越来越多地：
- 挂钩到现有框架
- 在运行时修改 DOM 元素
- 仅在特定用户操作后触发
当静态扫描器或 CSP 规则观察到异常时，损害已经发生。
传统工具的局限性
黑名单、离线扫描器和基于规则的系统是为可预测的威胁设计的。DOM 注入既不可预测也非静态——它们在会话中实时组装，执行后往往消失。
这并非小众边缘案例或理论上的担忧。根据 Omdia 研究在 VentureBeat 中的引用，去年绝大多数企业遭遇了基于浏览器的攻击活动，许多攻击完全在已认证的浏览器会话中执行，传统安全控制几乎没有可视性。
在各类事件中模式一致：攻击者无需绕过外围防御或利用零日漏洞。相反，他们在受信任的浏览器环境中操作，滥用合法的执行路径，而现有工具从未设计在访问已获授权后进行监控。
常见的 DOM‑Level 攻击模式
尽管实现方式多样，大多数 DOM 注入可归为以下几类行为：
- 界面操控 – 替换链接、按钮或 UI 元素，以重定向用户或拦截操作。
- 输入拦截 – 捕获按键、表单数据或用户交互，并悄悄外泄。
- DOM 伪造 – 渲染看似原生的虚假横幅、弹窗或嵌入式表单。
- 策略滥用 – 利用受信任的加载器、子域或宽松的 CSP 规则，在不违反策略约束的情况下执行恶意逻辑。
为什么静态规则不足
一个关键的误解是 DOM 注入仅是语法层面的问题。并非如此。
大多数恶意行为源自一系列动作，而不是单个 API 调用。单独一次 appendChild 或 setAttribute 调用通常并不构成可疑。
关键在于：
- 何时发生
- 会话中还有什么其他操作
- 它与用户行为的关联程度
这正是纯规则检测失效的地方。
混合检测模型
一种有效的解决思路是将直接运行时观察与会话级行为分析相结合。
运行时 DOM 插装
此方法不对代码进行扫描，而是监控 DOM 在执行期间的实际修改情况。通过观察对敏感 DOM API（例如节点插入、属性变更、动态求值）的调用，可以检测出与预期修改模式的偏差——即使注入的代码已被混淆或是瞬时的。
会话级关联分析
DOM 注入很少单独出现。它们通常伴随以下现象：
- 异常的导航模式
- 重复刷新或渲染卡顿
- 浏览器 API 行为不一致
- 自动化或合成交互的迹象
将这些信号一起分析，有助于区分合法的动态行为与注入的恶意操作。
实际数据揭示的情况
当将该混合方法应用于真实流量时，会出现以下几种模式：
- 单次 DOM 注入出现频率出乎意料地高，往往来源于被攻陷或权限过宽的第三方组件。
- 包含多次关联注入的会话较为少见，但风险显著更高。
- 大量高风险注入场景完全被静态或基于特征的系统漏检。
关联分析通过提前过滤良性动态行为，大幅降低了人工调查的时间成本。
Key takeaway: 大多数 DOM 注入是可检测的——但不能单独检测。
发展方向
随着客户端执行变得愈发复杂，检测模型需要从“代码长什么样”转向“会话如何表现”。该领域的未来改进倾向于关注：
- 更丰富的客户端遥测
- 更好地将 DOM 变化与用户操作关联
- 在注入逻辑影响用户之前更早的干预点
这不仅仅是阻止脚本，而是要理解执行上下文。
结束语
DOM 注入利用了静态分析与运行时行为之间的盲点。防御它们需要接受以下事实：
- 恶意代码可能永远不存在可读形式。
- 执行上下文比语法更重要。
- 浏览器端的可见性不再是可选的。
静态防御仍有其作用——但没有 runti
“他们将继续错过最微妙且破坏性最大的客户端攻击。”
Me and Behavioral Insight
Disclosure: 本文基于团队在 JuicyScore 的应用研究和生产工作撰写。实现细节已被概括，以聚焦于架构原则而非产品细节。