SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场multi-account-isolation

multi-account-isolation

安全与审计

查看项目

更新于 10-13 20:08

技能介绍

multi-account-isolation 是一个浏览器配置文件隔离验证技能。它的核心立场是：看似隔离的 profile 通常并未真正隔离，失败原因往往是机械而乏味的，例如时区与出口 IP 不匹配、WebRTC 候选地址携带真实地址、canvas 哈希每次读取都变化、两个 profile 最终落在同一个 persona 上。该技能提供一份检查清单，用于在这些问题产生影响之前将其捕获。

用途

该技能用于验证自己拥有或获授权操作的身份之间是否真正隔离，包括自己的账号、自己的测试夹具、自己的 QA 集群以及自己的反欺诈栈。它明确不适用于未授权访问系统、登录他人账号，或创建虚假账号与互动。使用者需遵守所自动化站点的条款和适用法律。

配置不变量

该技能强调一个身份对应一份配置：identity → profile → persona → proxy → timezone 应为一对一关系。任意两个身份之间共享任何一格都是需要发现的缺陷。由于 antibrow 各方案中 profile 数量不限且免费，因此没有理由复用 profile。在同一个 profile 内“退出再以另一身份登录”会破坏整个设置，因为 cookie jar 和 localStorage 才是关键。

主要能力

技能列出了十一项检查，每项都要求通过断言而非肉眼观察来完成，并且每个 profile 需通过自己的代理运行：

  1. 时区与出口 IP 匹配：比较 browser.timezone 与 browser.public_ip 的国家。失败通常是因为禁用 geoip 或强制设置了与 IP 矛盾的时区，这是最常见的缺陷。
  2. WebRTC 仅暴露代理：通过 browserleaks.com/webrtc 检查 ICE 候选是否仍携带本地或真实公网地址。
  3. Canvas 哈希跨启动稳定：读取后关闭，重新启动同一 profile 再读取，若两次不同则说明 persona 未冻结。
  4. Worker 与主线程一致：通过 CreepJS 检查 UA、语言、hardwareConcurrency、时区或 GPU 在 Web Worker 中重新读取时是否不同。
  5. 三个接口共用同一 GPU：通过 CreepJS 或直接读取 WebGL / WebGL2 / WebGPU，检查 adapter.info.vendor 是否与未掩码的 WebGL 渲染器家族匹配。
  6. 没有两个 profile 共享 persona：对比整个集群的 browser.persona，若两个 profile 报告相同 UA、屏幕几何和种子则失败。
  7. 没有两个 profile 共享地址：收集整个集群的 browser.public_ip，若两个身份来自同一出口或同一 /24 则失败。
  8. Cookie jar 相互独立：对比整个集群的 browser.profile_dir，再检查每个目录内的 user-data/。若两个身份解析到同一目录，或一个目录持有属于另一身份的状态则失败。
  9. 一个身份一棵 profile 树：确认同一名称的每次启动都传入相同的临时值。一个受管理的 gmail 和一个临时 gmail 是两个不同 profile，具有两个 persona 和两个 cookie jar。
  10. 整栈一致性：通过 whoer.net、pixelscan.net 检查 IP、时区和语言是否一眼矛盾。
  11. CI 中的一致性规则：运行 npx liarjs（liarjs.dev），若约 40 条开源跨层规则任一失败则失败，这是可无人值守运行的一项。

其中第 1、3、7 项被建议接入 CI，因为它们成本低、确定性强，且能捕获实际反复出现的缺陷。

使用方式

文档提供了 JavaScript 和 Python 的示例代码。JavaScript 使用 anti-detect-browser 包的 AntiDetectBrowser 类，为每个身份传入 profile、proxy、fingerprint.tags 和 label，启动后运行检查再关闭。Python 使用 antibrow 的 launch 函数，传入 profile、从环境变量读取的 proxy、geoip=True 和 label，并打印 browser.timezone 与 browser.public_ip。两个示例均强调代理凭据来自环境变量而非字面量。

阅读失败结果

文档建议按成本从低到高排查：先检查 profile 名称是否复用（通过 list_profiles 或对比 browser.profile_dir；目录以 profile 的 id 命名而非名称，因此应匹配其中的 profile.json），再确认每个 public_ip 是否唯一，然后同时打印 browser.timezone 和 browser.public_ip 检查时钟与地址是否矛盾，接着检查 persona 是否被重新生成（若 canvas 哈希在启动间变化，检查 profile_dir 或缓存目录是否改变），最后才验证指纹本身。

运行时数据与验证

文档说明了 antibrow 运行时接触的数据及其位置：cookie、localStorage、登录状态位于本地 ~/.anti-detect-browser/profiles/<id>/user-data/ 或临时 profile 的 profiles-temp/<id>/，云端同步需按 profile 显式开启，sync: true 才会创建云 profile。persona 写入同一 profile 目录下的 persona.json，一次写入后冻结。profile 身份记录位于 profile.json，其 id 决定目录名。代理 URL 和凭据在启动时传给内核，由网络栈应答（HTTP 407 / SOCKS5 RFC 1929），不经过扩展。API key 位于环境变量或 ~/.antibrow/license.key，会与 antibrow.com 交换短时许可证令牌，约每天一次。内核是闭源 Chromium 构建，因此建议验证行为：可用 python -m antibrow info 查看内核、profile、许可证状态和缓存目录，用 browser.plan.redacted_args() 查看脱敏后的内核命令行，并将流量指向可读日志的代理或本地 MITM 代理。文档还建议固定 SDK 版本并检查发布哈希，若部署不能联网回传则不应使用该工具，因为许可证验证已编译进内核且没有离线模式。

适用场景与限制

适用场景包括：验证自己拥有的身份之间的隔离、在账号持有者授权下运行客户账号、构建模拟不同设备的 QA 夹具、测试自己的反欺诈与关联逻辑、审计浏览器运行时如何处理凭据。

不适用且不支持：未授权访问任何系统、登录不属于自己的账号、撞库或账号接管、创建虚假账号/评论/互动、规避身份验证/支付/授权控制、违反适用法律抓取个人数据、绕过平台的执行决定。

隔离无法覆盖的范围：浏览器之外的因素，如共享的支付工具、联系方式、收款目的地；活动模式，如相同的时间、内容和交互目标；身份验证；平台自身的决定。文档提醒，若所有检查通过但仍有问题，原因在此列表而非浏览器层。

相关技能包括 anti-detect-browser（创建并启动被验证设置的 SDK）和 browser-mcp-agent（MCP 服务器模式，让 AI 代理驱动单个 profile）。

许可证与合规由操作者自行负责。滥用或安全问题可通过 https://antibrow.com 的联系方式报告。