浏览器自动化登录场景下的驱动特征隐匿与中间人拦截实践

一、问题背景：登录环节为何成为自动化采集的第一道难关

在数据采集类项目中，目标站点通常不会允许匿名访问核心数据，必须先完成用户身份认证，才能获取后续请求所需的会话凭证（Cookie、Token 等）。因此，登录流程是整个采集链路的前置环节，也是最容易被风控系统重点布防的环节。

登录环节的防护手段大致可以分为两类：

• 交互层防护：滑块拖拽、图形点选、行为轨迹校验、无感验证等。这类手段主要验证操作者是否为“人”，通常通过鼠标移动轨迹、点击时间间隔、加速度曲线等特征建模判断。
• 环境层防护：检测浏览器运行环境是否存在自动化特征，例如驱动注入产生的全局变量、事件响应差异、浏览器指纹异常等。这类手段不依赖用户行为，而是直接判断“这个浏览器是不是被程序控制的”。

交互层防护可以通过模拟轨迹、变速拖拽等方式绕过；而环境层防护往往更加隐蔽——它不弹出任何验证框，只是在后台静默采集特征，一旦命中就直接拒绝下发凭证或返回错误数据。这使得很多项目在“看起来登录成功”的情况下依然拿不到有效会话。

二、检测原理：自动化特征是如何被读取的

自动化驱动的本质，是通过进程间通信让外部程序控制浏览器。为了支持这种控制，驱动会向页面上下文注入一批全局对象与属性，供脚本调用。这些注入物在生产环境中并不存在，因此天然成为可识别的“指纹”。

常见的特征维度包括：

1. 全局属性探测：页面脚本遍历 window.navigator、window.document 等对象，检查是否存在驱动特有的属性名，如与 webdriver 相关的布尔标记、与特定驱动命名空间相关的缓存对象等。这类属性一旦存在，即可判定为自动化环境。
2. 属性值一致性校验：某些属性在正常浏览器中应为 false 或 undefined，在自动化环境中却被置为 true 或注入对象。脚本读取后与预期值比对即可发现异常。
3. 函数原型差异：驱动注入的函数其 toString() 结果、原型链结构往往与原生函数不同，脚本可通过对比函数源码特征进行识别。
4. 行为响应差异：部分检测会触发一次特定的脚本执行，观察回调时序、参数结构是否符合原生行为。

需要强调的是，这类检测代码通常被混淆并封装在站点的主业务脚本中，随页面一同下发。也就是说，检测逻辑是随响应内容一起到达浏览器的。这一特点为拦截方案提供了切入点。

三、方案总体思路：在响应链路中动态清洗特征

既然检测逻辑来自服务端下发的脚本文件，那么可以在脚本到达浏览器之前对其进行改写，使检测代码“读不到”特征，或者读到的是被替换后的安全值。这种思路属于典型的中间人（MITM）拦截改造：在代理层截获响应，对响应体做定向替换，再转发给浏览器。

相比直接修改本地驱动文件或使用浏览器启动参数隐藏特征，该方案的优势在于：

• 针对性强：只改写与检测相关的脚本，不影响其他资源的完整性；
• 可维护：特征清单与替换规则集中在一处，便于随检测更新而调整；
• 无需侵入业务代码：采集脚本本身不需要感知代理的存在，只需让流量经过代理即可。

其局限也很明显：属于“对抗式”方案，依赖对检测脚本的定位与特征清单的持续维护；一旦站点更换检测实现或对响应做完整性校验，方案可能失效。因此它更适合作为技术研究与联调阶段的辅助手段，而非长期稳定的生产方案。

四、实施步骤

4.1 环境准备与代理配置

选用支持可编程拦截的中间人代理工具，安装后启动监听端口。核心工作是把浏览器的全部流量导向该代理，使页面请求与响应都经过拦截层。

配置要点：

• 代理地址设为本地回环地址，端口与启动参数保持一致；
• 若目标站点使用 HTTPS，需在浏览器或系统中信任代理生成的根证书，否则响应无法解密，替换也就无从谈起；
• 建议为自动化任务单独使用一个浏览器实例或独立配置目录，避免影响日常浏览环境。

4.2 定位检测脚本

打开浏览器开发者工具的网络面板，在登录流程中观察加载的脚本资源，重点排查体积较大、命名含业务含义的主脚本。定位方法有两种：

• 静态检索：在脚本内容中搜索特征关键字（如与驱动标记相关的属性名），命中所在文件即为检测载体；
• 动态断点：在 window 属性读取处下断点，观察调用栈，回溯到发起检测的脚本文件。

实践中，检测逻辑常集中在站点的核心业务脚本中，文件名往往带有固定前缀，可据此做前缀匹配，减少规则数量。

4.3 编写响应改写脚本

拦截脚本的核心逻辑是：匹配目标脚本的 URL，对响应文本执行批量替换。替换策略分为三类：

1. 属性名替换：把特征属性名替换为一个不存在的占位名，使检测读取到 undefined；
2. 布尔值翻转：把驱动标记的 true 改为 false，使一致性校验通过；
3. 命名空间清理：删除驱动相关的命名空间字符串，切断特征关联。

示意性代码如下（结构参考，非可直接运行的生产脚本）：

import re
from mitmproxy import ctx
# 特征清单：集中维护，便于随检测更新而扩充
FEATURE_KEYS = [
    "webdriver",
    "__driver_evaluate",
    "__webdriver_evaluate",
    "__selenium_evaluate",
    "__driver_unwrapped",
    "__webdriver_unwrapped",
    "_Selenium_IDE_Recorder",
    "_selenium",
    "calledSelenium",
    "_WEBDRIVER_ELEM_CACHE",
    "driver-evaluate",
    "webdriver-evaluate",
    "selenium-evaluate",
    "webdriverCommand",
    "__webdriverFunc",
    "$chrome_asyncScriptInfo",
]
# 目标脚本匹配规则：按文件名前缀识别
TARGET_PATTERN = re.compile(r"/js/core\.")
def response(flow):
    if not TARGET_PATTERN.search(flow.request.url):
        return
    body = flow.response.text
    for key in FEATURE_KEYS:
        # 1) 属性名替换为占位符
        body = body.replace(f'"{key}"', '"NO_SUCH_ATTR"')
        body = body.replace(f"'{key}'", "'NO_SUCH_ATTR'")
    # 2) 布尔标记翻转
    body = body.replace("t.webdriver", "false")
    body = body.replace("navigator.webdriver", "false")
    # 3) 命名空间清理
    body = body.replace("ChromeDriver", "")
    flow.response.text = body
    ctx.log.info(f"patched: {flow.request.url}")

几个工程细节值得注意：

• 替换顺序：先做长字符串替换，再做短字符串替换，避免短串先命中导致长串匹配失败；
• 引号形式：脚本中属性名可能以单引号、双引号或无引号形式出现，规则应覆盖多种写法；
• 编码问题：部分响应为压缩传输，需确保代理层已解压后再做文本替换，替换完成后按原编码回写；
• 幂等性：规则应可重复执行而不产生副作用，便于调试时反复请求。

4.4 启动与验证

退出调试状态，以加载拦截脚本的方式重新启动代理并监听同一端口。验证环节建议分三步：

1. 代理连通性：访问一个回显 IP 的页面，确认流量确实经过代理；
2. 替换生效：在浏览器中直接请求目标脚本 URL，检查响应内容中的特征名是否已被替换；
3. 端到端验证：完整走一遍登录流程，观察是否仍触发环境校验，成功后检查会话凭证能否正常用于后续接口请求。

若验证失败，按“代理是否生效 → 脚本是否解密 → URL 规则是否命中 → 替换是否覆盖实际写法”的顺序逐层排查。

五、方案局限与工程化建议

该方案在实践中会遇到几类典型问题：

• 规则失效：站点更新脚本结构或更换特征名，替换规则需要同步维护。建议把特征清单外置为配置文件，并记录每次失效时的检测变体，形成可复用的特征库。
• 完整性校验：若站点对脚本做哈希校验或签名验证，改写后的内容会被识别为篡改。此时需要评估是否改用其他路径。
• 性能开销：全量流量经代理转发会带来额外延迟，对大体积脚本做全文替换也有 CPU 成本。可通过限定 URL 匹配范围、仅在登录阶段启用代理来缓解。
• 多环境差异：不同浏览器内核、不同驱动版本注入的特征并不一致，特征清单需按实际环境裁剪。

从更长远的角度看，这类对抗本质上是“检测—规避”的持续博弈。工程上更稳妥的做法是：

1. 优先使用官方提供的自动化协议与调试接口，减少非必要的特征注入；
2. 控制访问频率与行为模式，让请求特征接近真实用户，降低被环境校验之外的风控策略命中的概率；
3. 遵守目标站点的服务条款与 robots 约定，仅在获得授权的范围内开展数据采集；
4. 把此类技术用于自身系统的自动化测试与兼容性验证，例如在回归测试中模拟真实浏览器环境，而不是用于绕过他人站点的访问控制。

六、小结

本文从登录环节的风控构成出发，说明了自动化特征被读取的技术路径，并给出了一套基于中间人代理的响应改写方案：通过代理拦截目标脚本、批量替换特征标识、翻转布尔标记、清理命名空间，使页面侧的检测逻辑读取不到有效特征。方案的关键在于检测脚本的准确定位与特征清单的持续维护，其价值更多体现在理解检测机理与验证防护强度，而非作为长期稳定的采集手段。在实际项目中，应结合合规要求、访问策略与官方接口能力综合选型，避免过度依赖单一对抗技巧。