# 为浏览器自动化设计攻防策略：检测模型与分层控制平面

本文聚焦于浏览器自动化攻防策略设计，分为两部分：

1. 原则：风险评分系统如何得出结论
2. 控制平面：分层设计如何降低风险与波动

本文不包含命令行操作或工程实现步骤。

Turnstile 相关内容请参见： Cloudflare Turnstile 攻防策略设计：系统原则与控制平面

1. 原则

1.1 风险评分不是单点命中

在高风控站点上，“是否挑战 / 是否降权”这类决策通常来自多维评分，而不是某一条规则的二元判断。

主要输入维度：

1. 一致性：同一身份在不同表面之间是否自相矛盾
2. 稀有性：是否出现低频异常组合
3. 时间性：行为时间序列是否呈现机械化统计特征
4. 执行完整性：关键路径（挑战脚本、跨源资源、worker）是否被破坏

flowchart LR
  A["环境和行为"] --> B["一致性评分"]
  A --> C["稀有性评分"]
  A --> D["时间评分"]
  A --> E["执行完整性评分"]
  B --> F["总体风险"]
  C --> F
  D --> F
  E --> F
  F --> G{"放行 / 挑战 / 限速"}

1.2 一致性：约束集，而不是单点调整

一致性的本质是：“同一身份在多个被观测表面上的约束必须同时成立。”

1.2.1 约束集示意

可以将身份一致性建模为“约束图”：

flowchart TD
  UA["UA 字符串"] --> UACH["UA-CH / userAgentMetadata"]
  UA --> LangH["Accept-Language"]
  LangH --> LangJS["navigator.language(s)"]
  LangJS --> Intl["Intl locale/timeZone"]
  Plat["platform"] --> Rend["渲染能力 / WebGL"]
  Rend --> Win["窗口 / 屏幕参数"]
  UACH --> Plat

图中的每条边都表示“两类表面必须彼此一致”；否则会产生冲突评分。

1.2.2 典型冲突类型

• UA 指示的平台/版本与 UA-CH 不一致
• Accept-Language 与 navigator.languages 不一致
• Intl 时区与推断出的偏移/地区不一致
• 设备声明与渲染能力之间存在异常组合

工程含义：

• 修复一个点可能破坏另一个点
• 设计顺序应当是“先定义约束集，再决定各个表面如何满足约束”

1.3 稀有性：组合风险，而不是单值风险

稀有性来自“低频组合”，危险来自共现，而不是任何单个项目。

可以将稀有性理解为相对于“联合分布”的偏离：

• 单特征偏离：可能被容忍
• 多特征共现偏离：风险会快速累积

工程含义：

• 目标是在同一个会话中减少低频组合的叠加
• 目标不是拟合一个固定人设

1.4 时间性：统计特征，而不是行为语义

行为检测通常关注统计分布特征：

• 低方差：动作之间的间隔过于稳定
• 强周期性：间隔遵循固定节奏
• 强同步性：不同动作类型之间的间隔相同

工程含义：

• 行为治理的目标是“分布塑形”（方差/抖动/退避）
• 行为治理不是“增加更多动作”

1.5 执行完整性：上游条件

执行完整性是“系统能否正确运行”的前提。

• 当挑战脚本、跨源 iframe 或跨源 worker 的语义被破坏时，失败率会显著上升
• 此类失败可能与“是否被识别”属于不同类别的问题

工程原则：

保护执行链优先于调整信号。

1.6 反调试执行表面：与指纹评分表面并行

许多站点不仅依赖指纹评分，还会部署“主动处置型反调试”脚本。

典型路径：

flowchart LR
  A["页面启动"] --> B["反调试探测"]
  B --> C{"命中？"}
  C -->|是| D["关闭 / 后退 / 重定向"]
  C -->|否| E["继续业务逻辑"]

它与指纹评分表面的关系：

1. 指纹评分决定“挑战 / 放行 / 降权”
2. 反调试处置决定“页面是否还能使用”

因此，“页面自行关闭”不能直接推断为“指纹被识别”；更常见的情况是反调试链被触发。

2. 控制平面（分层设计）

2.1 控制平面概览

攻防策略可以拆分为四个控制平面：

1. 启动控制：在启动早期治理显式风险
2. 协议控制：在协议层治理身份一致性
3. 运行时控制：治理页面脚本可观测的表面
4. 行为与会话控制：治理时间分布与上下文漂移

flowchart LR
  A["启动控制"] --> B["协议控制"]
  B --> C["运行时控制"]
  C --> D["行为与会话控制"]
  D --> E["一致性与稳定性"]

2.2 启动控制

目标：在会话早期降低显式风险。

设计约束：

• 只处理高置信度的自动化标识
• 避免引入会与协议层/运行时层不一致的变更

2.3 协议控制

目标：在协议层输出中实现身份约束集。

设计要点：

• 将 UA 与 UA-CH 视为同一约束集的不同投影
• 覆盖范围必须与目标一致（页面/worker/子目标）

2.4 运行时控制

目标：覆盖高频探测表面，同时确保执行语义不被破坏。

设计要点：

• 优先治理高频、可解释的探测路径
• 对跨源挑战链对象设置严格注入边界

2.4.1 反调试脚本治理（以 disable-devtool 类库为例）

反调试脚本通常通过固定启动入口触发（例如 disable-devtool-auto 标记）。

可行的控制策略：

1. 只抑制自动启动入口，避免触发主动处置
2. 不重写通用查询/脚本加载语义，避免影响业务页面
3. 将治理范围限制在高置信度触发点，以控制副作用表面

这些策略的本质是“执行表面隔离”，而不是“伪造更多指纹”。

2.5 行为与会话控制

目标：塑造时间分布并减少上下文漂移。

设计要点：

• 行为治理面向统计分布（方差/抖动/退避）
• 会话治理面向上下文一致性（避免身份漂移）

2.6 挑战场景（Turnstile）的控制平面总结

在 Turnstile 场景中，关键控制平面可抽象为：

1. 能力令牌语义：服务端验证、有限有效期、一次性消费
2. 范围收缩：hostname/action/cdata 缩小滥用空间
3. 执行链保护：保护跨源脚本/iframe/worker 的语义
4. 摩擦与安全分离：clearance 属于体验层，不能替代安全决策层

该总结用于将 Turnstile 纳入统一的控制平面框架；详见专门文章。

3. 方案设计优先级

控制平面设计通常按以下优先级推进：

1. 执行完整性（确保链路能够运行，包括对反调试触发表面的治理）
2. 一致性约束集（消除跨表面矛盾）
3. 稀有性控制（避免低频组合叠加）
4. 时间分布塑形（减少机械化统计特征）
5. 体验优化（减少重复挑战带来的摩擦）

这一顺序的意义是：先确保“系统正确性”，再优化“稳定性与摩擦”。