基于 WebSockets 的时序攻击：反欺诈系统如何扫描您的本地端口

您想以折扣价格尝试 Octo 浏览器吗？
使用促销代码 OCTOSCRAPER 获得任何订阅 30% 的折扣。此优惠仅适用于新用户。

WebSocket 深度解析：它如何演变为本地扫描器

首先，我们来做一点背景介绍。WebSocket 是一种基于 TCP 的通信协议，旨在实现客户端与服务器之间实时的消息交换。

最初，它的创建是为了在极低延迟下实现浏览器游戏，或在聊天应用中实现实时输入指示器。但在防欺诈系统的开发者们很快意识到，如果浏览器可以向远程服务器打开一个套接字，那么在大多数情况下，也没有什么能阻止它尝试连接用户的本地地址。

其工作原理如下：一旦目标网页加载完毕，或者在您登录时，一个隐藏的防欺诈脚本就会开始异步尝试建立连接。它并不会扫描每个可能的端口，而是通过预先定义的端口列表来探测 127.0.0.1。例如用于 CDP 的 9222 端口，或本地 VPN 客户端和数据库服务器常用的端口。在大多数情况下，这种方法行之有效。

为什么浏览器允许这种操作

现代浏览器和操作系统具有两个架构特性，使得这种操作成为可能。

1. 绕过严格的 CORS 限制。如果防欺诈脚本试图使用常规的 HTTP 请求（通过 fetch() 或 XMLHttpRequest）来扫描端口，浏览器会因为其安全措施、同源策略、CORS 限制和混合内容规则而阻止对响应的访问。但 WebSockets 的工作原理不同。该协议不使用传统的 CORS 模型来限制对响应的访问，而是发送一个 Origin 请求头，服务器可以选择对其进行验证。仅仅是判断连接成功还是失败，就已经能为分析提供极具价值的信息。

2. 防火墙的盲区。在操作系统中，环回（loopback）接口（127.0.0.1）享有极高级别的信任，因为从浏览器发送到本地端口的流量永远不会离开您的网络接口。

因此，Windows 和 macOS 中内置的防火墙通常不会检查或过滤这些内部连接，而是将它们视为本就安全的连接。

这为防欺诈系统提供了一个合法的、本质上不受限制的通道，来探测您的本地环境。

但是，如果浏览器的安全策略阻止了它们读取直接的系统响应，它们又该如何判断某个端口是否开放呢？

这就是时序攻击发挥作用的地方。

时序攻击的工作原理

浏览器沙箱对脚本施加了严格的限制。由于同源策略（SOP）和 CORS 限制，脚本无法直接读取本地服务的响应，也无法获取连接失败时返回的确切错误代码。然而对时序攻击来说，幸运的是，它根本不需要这些信息。

其运行流程如下：

1. 脚本启动一个内部计时器（通常使用 performance.now()）。

2. 它发起一个 WebSocket 连接：
   new WebSocket('ws://127.0.0.1:9222')

3. 脚本等待 onerror 事件触发。

4. 一旦发生错误，计时器停止，并计算出耗时。

其核心关键在于操作系统的网络栈处理 TCP 连接的方式：

1. 如果端口关闭。操作系统会通过立即返回一个 TCP RST 数据包来拒绝传入的 SYN 包。浏览器关闭套接字并触发 onerror 处理程序。在本地机器上，这通常只需 1-5 毫秒。

2. 如果端口开放。首先会完成一个完整的 TCP 三次握手。随后，浏览器发送一个 HTTP Upgrade 请求以建立 WebSocket 连接。即使在该端口上监听的服务实际上并不是 WebSocket 服务器（例如数据库或 SSH 守护进程），连接也不会立即终止。相反，它只有在检测到协议不匹配后才会失败。握手和数据交换所需的额外时间将延迟拉长至大约 10-50 毫秒。

3. 如果端口被防火墙过滤。防火墙会静默丢弃 SYN 数据包，而不是拒绝它。浏览器得不到操作系统的任何响应，只能一直等待直至系统超时。在这种情况下，延迟是以秒而非毫秒来计算的。

现代浏览器刻意将计时器精度降低到大约 0.1–1 毫秒。但是，网络时序攻击并不需要纳秒级的精度。

即时的 TCP RST 与延迟的连接尝试之间的差异在几十毫秒左右，这对于可靠的检测来说已经绰绰有余了。

先进的防欺诈系统还会考虑 CPU 负载、JavaScript 垃圾回收以及操作系统的行为等因素，因此它们不依赖硬编码的阈值。

相反，脚本首先会自行进行校准。

在探测其真正感兴趣的端口之前，它会尝试连接一个故意随机生成的、高位的、且推测为关闭的端口，例如：

ws://127.0.0.1:54321

这为当时您特定机器上关闭的端口确立了一个基准响应时间。

然后，防欺诈系统会将与多账号工具有关的常用端口的耗时与该基准进行对比，从而识别出异常情况。

为什么防欺诈系统如此关心您的本地主机 (localhost)

防欺诈系统的首要目标是去匿名化浏览器配置文件并检测多账号关联。

大多数反检测解决方案都高度专注于伪装浏览器指纹——Canvas、WebGL、字体及类似信号——而对网络栈的关注则少得多。

与自动化工具关联的开放本地端口，成为了数字身份被伪装的极高可信度指标。

评分算法在寻找什么

在不足一秒的时间内收集到的时序数据会被发送到防欺诈评分服务器。

在服务器端，系统会分析观测到的端口模式。根据结果，可能会在您配置文件的整体评分中增加负面的风险分值。

如果 9222 端口是开放的，这强烈表明该浏览器正通过 Chrome DevTools Protocol (CDP) 被诸如 Puppeteer、Playwright 或 Selenium 等自动化框架所控制。

在这种情况下，模拟鼠标轨迹或模拟人类输入通常于事无补。根据防欺诈系统的严格程度，该会话可能会被赋予极高的风险分，从而导致从弹出 CAPTCHA 验证码到账号直接被封禁等一系列后果。

同样，如果诸如 22 (SSH)、3306 (MySQL) 或本地代理应用常用的端口是开放的，也很难将自身伪装成普通的个人用户设备。

防欺诈系统很可能会判定它正在应对一台虚拟机、一台租用的服务器，或一个专业的多账号工作站，从而大幅度降低赋予该账号的信任度。

交叉关联与账号农场检测

这可能是任何管理多个账号的人员最担心的问题。

假设您在单台机器上运行着 50 个浏览器配置文件。

每个配置文件都拥有：

• 唯一的浏览器指纹；

• 专属的代理服务器；

• 以及不同的 IP地址。

对于外部网站而言，它们看起来就像是 50 个不同的个体。然而，底层操作系统或服务器依然是同一个。

这意味着后台运行着相同的服务，暴露着完全一致的开放端口。这种开放端口的独特组合实际上可以演变成一种“超级指纹”。

防欺诈系统能识别出这五十个原本看似毫无关联的用户，竟然共享着完全相同的、极不寻常的本地服务配置。随后它可以将它们关联并归为同一个账号农场，最终对整个群组进行隐形封禁（Shadow-ban）。

换句话说，通过扫描本地主机，反机器人系统可以穿透您的浏览器指纹，揭示支撑您多账号体系的真实底层基础设施。

如何保护自己：隔离和防火墙配置

在应对复杂的防欺诈系统时，您的防护策略应当基于以下原则：

1. 隔离网络栈。使用配置了严格网络隔离环境的虚拟机或容器。如果浏览器运行在一个完全隔离的环境中，时序攻击将只能返回端口关闭的标准响应时间，因为主机上运行的服务在物理上无法从虚拟环境中访问。

2. 正确配置您的防火墙。您的防火墙不应该只是简单地默默拦截连接请求，而应该立即拒绝它们。具体来说，请使用 REJECT（它会立刻返回 TCP RST 包），而不要使用 DROP（它会静默丢弃数据包并迫使浏览器等待超时）。REJECT 响应模拟了端口自然关闭的行为，因此在基于时序的检测算法面前不会显得可疑。

3. 彻底阻断对 localhost 的访问。最彻底但也最有效的方法是完全禁止浏览器访问 localhost。这能瞬间让试图探测您系统的防欺诈脚本彻底失效。

然而，这种方法也有弊端：一些合法的应用，例如硬件安全密钥或电子签名工具的软件，需要通过本地代理进行通信。失去对这些服务的访问权限本身可能会成为一种异常，从而导致风险分升高。

因此，有两种实用的方法可供选择：

• 细粒度过滤。在防火墙或浏览器扩展程序级别，仅允许访问可信的本地服务，同时对于任何试图向未知的本地端口建立 WebSocket 网络连接的后台尝试，一律予以立即拒绝（使用 REJECT）。

• 使用专业工具。另一个选择是依赖在浏览器内核级别处理此问题的软件，例如反检测浏览器。

例如，Octo Browser 包含了针对本地端口扫描的内置防护机制。Octo 会拦截脚本（包括使用 WebSocket API 的脚本）访问 127.0.0.0/8 范围或 localhost 的所有尝试，直接在浏览器 API 级别对其进行处理。

测试防护措施

您可以通过一个简单的测试轻松查看其工作原理。

第一步，在您的设备上启动任何本地服务器，使其打开一个监听端口。

开放的端口看起来类似于这样。

接下来，在您的浏览器中打开任意网站，并尝试访问该开放端口。

在标准的 Chrome 浏览器中，响应会伴随轻微延迟抵达。这一延迟便印证了该端口处于开放状态。

在 Octo Browser 中进行相同的测试，您会发现该端口呈现为关闭状态。

Octo Browser 控制着对您本地端口的访问，以防止数据泄露。

专用网络访问 (PNA) 能解决这个问题吗？

专用网络访问（PNA）是现代浏览器（主要是 Chrome）中实施的一项安全特性，旨在阻止公共网站向用户本地网络上的设备或服务器发送请求。

现代浏览器确实试图通过以下方式缓解这一漏洞：

• 限制或完全阻止从不安全的公共上下文中访问 localhost；

• 在发起此类连接之前，强制要求安全上下文（HTTPS）；

• 在允许访问本地网络资源之前，执行 CORS 预检（preflight）请求。

然而，防欺诈系统的开发者们也早已适应了这一点。他们使用解析到 127.0.0.1 的公共域名（例如 yourapp.localhost.com）配合有效的 HTTPS 证书，从而绕过其中一些基础限制。

更重要的是，PNA 无法保护您免受 TCP 级别的时序攻击。即使 PNA 因为缺少必需的请求头最终拦截了请求，浏览器也必须先建立 TCP 连接，然后才能确定这些请求头是否合格。如果端口关闭，操作系统会立即通过 TCP RST 包拒绝连接。如果端口开放，TCP 握手则成功完成。随后浏览器尝试交换数据，遇到 PNA 限制，终止连接，而后才报告错误。

这些额外的步骤需要消耗几十毫秒的时间，而这恰好就是防欺诈算法所依赖的时序差异。换句话说，PNA 阻止了网站读取本地数据，但它无法掩盖建立连接所需的时间。

结论

在今天，要实现行之有效的匿名，必须采用综合性的手段。您可以创建一个看似完美的浏览器配置文件，但一个遗忘的调试端口（如 9222）或暴露的数据库端口，就足以彻底击垮您近乎无懈可击的伪装。保护好您的网络栈：隔离您的工作环境，仔细配置您的防火墙，或者信赖在浏览器内核级别解决这类泄漏问题的解决方案。