Method for solving websocket hijacking problem based on security sandbox
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- CHINA LIFE INSURANCE CO LTD
- Filing Date
- 2026-07-03
- Publication Date
- 2026-08-07
AI Technical Summary
然而，此类基于应用层代码的事后加固方法存在若干根本性局限：其一，防御效果高度依赖于开发人员的实时安全编码意识，极易因通配符误配置、正则表达式边界处理疏忽或协议升级流程中的逻辑绕过而完全失效；其二，该种防护策略仅能针对已知的特定攻击向量进行被动式响应，无法从根本上改变WebSocket连接建立的信任模型，即未能将安全校验职责从存在潜在漏洞的应用层代码中剥离，因而难以抵御未来可能出现的未知协议降级攻击、控制帧注入攻击及零日（0-Day）漏洞利用；其三，现有网关默认信任本地回环流量，信任模型存在根本性缺陷，导致恶意网页可利用浏览器特性发起静默连接
[0025] The beneficial effects of the present invention’s method for solving the problem of OpenClaw being hijacked by WebSocket based on a security sandbox are as follows: (1) By deploying a security agent between the public network interface and the OpenClaw core gateway, the handshake traffic is forcibly taken over. Even if the application layer Origin header verification is completely invalid or bypassed, the attack traffic cannot directly reach the OpenClaw core gateway, thus realizing a paradigm shift from relying on the correctness of application logic to relying on the network isolation mechanism of the operating system; (2) It integrates connection handshake verification, sandbox environment isolation and real-time message content detection, and constructs a defense-in-depth system from the connection layer to the application layer. The three-layer progressive defense ensures that even if one layer is bypassed, the subsequent layers can still provide effective protection; (3) It separates the sensitive connection handshake and verification logic from the main application (OpenClaw core gateway) and places it in a security sandbox with minimal permissions, thus creating a solid security boundary. It transfers the trust judgment process from the OpenClaw gateway process to an independent security agent process. The security agent distinguishes between legitimate local clients and malicious browser processes, thus undermining the trust premise of CSWSH attacks.
Smart Images
Figure CN122533862A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of network security technology, and in particular to a method for solving the problem of OpenClaw being hijacked by WebSockets based on a security sandbox. Background Technology
[0002] With the rapid development of Internet of Things (IoT), 5G communication and artificial intelligence (AI) technologies, edge computing, as an architecture that pushes computing power down to the vicinity of the data source, is gradually becoming a key technology for solving high latency, bandwidth bottlenecks and data privacy issues.
[0003] Local AI agents, as a key application of edge computing, have experienced explosive growth in recent years. Open-source AI agent platforms, such as OpenClaw, allow users to run large language models on their local terminals, automatically performing high-privilege tasks such as code writing, file operations, terminal command execution, and system configuration management, significantly improving development efficiency and user experience. Currently, local AI agents commonly use the WebSocket protocol as their core control protocol, achieving real-time bidirectional communication between the browser UI, IDE plugins, and the local AI agent by running a WebSocket gateway on a local port. However, the security flaws in the WebSocket protocol's handshake phase make it highly vulnerable to cross-site WebSocket hijacking (CSWSH) attacks in the context of edge nodes where physical protection boundaries are blurred.
[0004] Currently, the traditional remediation methods used in the industry to combat Cross-Site WebSocket Hijacking (CSWSH) and broader WebSocket protocol layer attacks mainly focus on adding declarative validation of the HTTP Origin request header or Sec-WebSocket-Protocol sub-protocol fields in the application layer service code. However, this kind of post-hoc hardening method based on application layer code has several fundamental limitations: First, the defense effectiveness is highly dependent on the real-time security coding awareness of developers, and it is easily rendered completely ineffective by wildcard misconfiguration, negligence in regular expression boundary handling, or logical bypassing in the protocol upgrade process; Second, this protection strategy can only passively respond to known specific attack vectors and cannot fundamentally change the trust model for establishing WebSocket connections, that is, it fails to separate the responsibility of security verification from the potentially vulnerable application layer code, and therefore is difficult to resist future unknown protocol downgrade attacks, control frame injection attacks, and zero-day vulnerability exploits; Third, existing gateways trust local loopback traffic by default, which has a fundamental flaw in the trust model, allowing malicious web pages to use browser features to initiate silent connections. Summary of the Invention
[0005] To address the aforementioned technical problems, this invention provides a method for resolving the issue of OpenClaw being hijacked by WebSockets based on a security sandbox, comprising the following steps: S1: Deploy the security agent and configure the security agent, OpenClaw core gateway, and hosts to build a security sandbox. This includes the following sub-steps: S11 Deploy security agent; Deploy the pre-built security agent on the same host or virtual machine running OpenClaw.
[0006] The security agent is a standalone binary file or container image.
[0007] S12 configures the network for the security agent; Configure the security agent to listen on the public network interface, using the port that OpenClaw originally used.
[0008] S13 Configures policies for the security agent; Create and configure the security agent's policy file, defining a whitelist of legitimate Origin sources, DPI detection rules, and access control policies.
[0009] The Origin source whitelist is an application-layer access control mechanism. The server only accepts connection requests from sources specified in the Origin source whitelist and rejects access from all unauthorized sources. The access control policy specifies a complete set of rules regarding access, used to restrict the operation permissions of authenticated users.
[0010] S14 Modify the configuration file of the OpenClaw core gateway; The OpenClaw core gateway is the sole control center and communication hub of the entire OpenClaw system. It is a single-instance, long-running background daemon and the only access point for all clients, agents, and node devices.
[0011] Change the listening address in the OpenClaw core gateway configuration file from the port originally used by OpenClaw to the local loopback address or other local-only addresses and ports.
[0012] S15 Configure the host's firewall rules; This ensures that only the local security agent process can access the port of the local loopback address, thereby enforcing isolation at the operating system level as well.
[0013] With the above configuration, a secure sandbox is finally built.
[0014] S2: The client initiates a WebSocket handshake request to the OpenClaw core gateway. The security sandbox intercepts the WebSocket handshake request and verifies it. Based on the verification result, it decides whether to allow the client to initiate an internal WebSocket connection to the OpenClaw core gateway.
[0015] Furthermore, S2 includes the following sub-steps: The S21 client initiates a WebSocket handshake request; The client attempts to connect to the default WebSocket control port address of the local AI agent.
[0016] The S22 security sandbox first intercepts and captures WebSocket handshake requests; The S23 security sandbox performs origin verification on WebSocket handshake requests by checking the Origin field in the HTTP request header of the WebSocket handshake request. If the Origin field is not in the predefined whitelist of valid Origin sources, immediately return 403 Forbidden, blocking the client's internal WebSocket connection to the OpenClaw core gateway.
[0017] If the Origin field is in the predefined whitelist, meaning the source is legitimate, further check whether the WebSocket handshake request complies with the RFC 6455 specification; If the WebSocket handshake request is non-compliant, an error code will be returned and the internal WebSocket connection to the OpenClaw core gateway will be refused. If the WebSocket handshake request is compliant, an internal WebSocket connection to the OpenClaw core gateway is allowed.
[0018] S3: If the client is allowed to initiate an internal WebSocket connection with the OpenClaw core gateway, the security sandbox will initiate an internal WebSocket connection to the OpenClaw core gateway to transmit data, while performing real-time threat detection and handling.
[0019] After the security sandbox initiates an internal WebSocket connection to the OpenClaw core gateway, a bidirectional communication tunnel is formed, and all data between the client and the core gateway must pass through the security proxy.
[0020] Furthermore, the threat detection and handling includes the following steps: a) DPI Detection: The security sandbox parses each frame of data passing through the communication tunnel according to predefined DPI detection rules; DPI (Deep Packet Inspection) is an application-layer traffic analysis technique that not only examines network layer information such as IP and TCP headers, but also delves into the application-layer payload of data packets to identify protocol types, data content, and behavioral characteristics. This allows the security sandbox to understand all the content transmitted within internal WebSocket connections, rather than blindly forwarding data like a traditional gateway.
[0021] b) Signature matching: Detects whether the transmitted data contains malicious command injection, SQL injection, or other known attack signatures; Signature matching is a detection technique based on known threat signatures. It works by pre-building a malicious signature database (signature database), then comparing the content to be detected with the signatures in the database. If a match is found, the content is identified as malicious and blocked.
[0022] c) Behavioral analysis: Monitor the transmitted data for abnormal command sequences or unusually large data packets; d) Exception Handling: If abnormal behavior is detected in steps a)-c), perform the following operations according to the preset strategy: Immediately close the current internal WebSocket connection; Add the attack source IP or identifier to a temporary blacklist; Detailed attack logs are kept for post-incident analysis.
[0023] S4: If no threat is detected, the normal communication phase begins. The security sandbox forwards the transmitted data to the OpenClaw core gateway without modification. The OpenClaw core gateway performs business logic processing and sends the processing results back to the client through the security sandbox.
[0024] Furthermore, considering that introducing a security proxy layer inevitably introduces additional latency, the following optimization measures are taken to minimize the performance impact: 1) Use one of the compiled languages C++, Rust, or Go to develop the security agent to achieve near-native performance; 2) An event-driven, non-blocking I / O model is adopted to efficiently handle a large number of concurrent connections; 3) DPI detection uses an optimized string matching algorithm and a tailored regular expression engine to accelerate the signature detection process; 4) For DPI scenarios with encrypted traffic, utilize the CPU's AES-NI instruction set or a dedicated encryption / decryption hardware acceleration card to offload the TLS decryption load. 5) Compile the rules of high-level access control policies into lower-level, more efficient data structures or bytecode.
[0025] The beneficial effects of the present invention’s method for solving the problem of OpenClaw being hijacked by WebSocket based on a security sandbox are as follows: (1) By deploying a security agent between the public network interface and the OpenClaw core gateway, the handshake traffic is forcibly taken over. Even if the application layer Origin header verification is completely invalid or bypassed, the attack traffic cannot directly reach the OpenClaw core gateway, thus realizing a paradigm shift from relying on the correctness of application logic to relying on the network isolation mechanism of the operating system; (2) It integrates connection handshake verification, sandbox environment isolation and real-time message content detection, and constructs a defense-in-depth system from the connection layer to the application layer. The three-layer progressive defense ensures that even if one layer is bypassed, the subsequent layers can still provide effective protection; (3) It separates the sensitive connection handshake and verification logic from the main application (OpenClaw core gateway) and places it in a security sandbox with minimal permissions, thus creating a solid security boundary. It transfers the trust judgment process from the OpenClaw gateway process to an independent security agent process. The security agent distinguishes between legitimate local clients and malicious browser processes, thus undermining the trust premise of CSWSH attacks. Attached Figure Description
[0026] Figure 1 This is a flowchart illustrating a method for resolving the problem of OpenClaw being hijacked by WebSockets based on a security sandbox, according to the present invention. Detailed Implementation
[0027] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.
[0028] Example: Figure 1 As shown, this invention proposes a method for solving the problem of OpenClaw being hijacked by WebSockets based on a security sandbox, including: S1 deploys a security agent and configures the security agent, OpenClaw core gateway, and hosts to build a security sandbox. This includes the following sub-steps: S11 Deploy security agent; Deploy the pre-built security agent on the same host or virtual machine running OpenClaw.
[0029] The security agent is a standalone binary file or container image.
[0030] S12 configures the network for the security agent; Configure the security agent to listen on the public network interface, using the port 0.0.0.0:18789 that OpenClaw originally used.
[0031] S13 Configures policies for the security agent; Create and configure the security agent's policy file, defining a whitelist of legitimate Origin sources, DPI detection rules, and access control policies.
[0032] The Origin source whitelist serves as the first line of defense against ClawJacked vulnerabilities, specifically addressing the lack of cross-domain protection for WebSockets. It blocks WebSocket connections initiated by malicious web pages via browser JS from the source, ensuring that even if attackers lure users to malicious websites, they cannot establish a communication channel with the OpenClaw core gateway. As a second line of defense, DPI detection rules can still detect and block malicious commands and abnormal traffic even if attackers bypass Origin verification in some way, preventing attackers from performing high-risk operations. Access control policies, acting as the last line of defense, fundamentally solve the "localhost implicit trust" problem inherent in OpenClaw, implementing the principle of least privilege. Even if an attacker successfully establishes a connection, they can only operate within the scope of their assigned permissions and cannot gain complete control of the system.
[0033] S14 Modify the configuration file of the OpenClaw core gateway; Change its listening address from 0.0.0.0:18789 to 127.0.0.1:18790 or another locally-only address and port.
[0034] On the same host, different network interfaces can listen on the same port number. The security proxy listens on 0.0.0.0:18789, and OpenClaw listens on the local loopback address 127.0.0.1:18790. Both run simultaneously without port conflicts. At this time, any connection request from an external network or local browser will be routed by the operating system to the security proxy listening on 0.0.0.0:18789. Only the process running on the local machine, i.e., the security proxy, can connect to the OpenClaw core gateway listening on 127.0.0.1:18790.
[0035] S15 Configure the host's firewall rules; This ensures that only the local security agent process can access port 127.0.0.1:18790, thereby enforcing isolation at the operating system level as well.
[0036] The S2 client initiates an external request to the default WebSocket control port address of the OpenClaw local AI agent. The security proxy intercepts the external request and verifies it, and decides whether to allow the initiation of an internal WebSocket connection to the OpenClaw core gateway based on the verification result.
[0037] Furthermore, S2 includes the following sub-steps: The S21 client initiates a WebSocket handshake request; The client (which could be a legitimate console or a malicious website) attempts to connect to the local AI agent's default WebSocket control port address ws: / / 127.0.0.1:18789.
[0038] The S22 security sandbox first intercepts and captures WebSocket handshake requests; The S23 security sandbox performs origin verification on WebSocket handshake requests by checking the Origin field in the HTTP request header of the WebSocket handshake request. If the Origin field is not in the predefined whitelist of valid Origin sources, immediately return 403 Forbidden, blocking the client's internal WebSocket connection to the OpenClaw core gateway.
[0039] If the Origin field is in the predefined whitelist, meaning the source is legitimate, further check whether the WebSocket handshake request complies with the RFC 6455 specification. Specifically, check the Upgrade, Connection, Sec-WebSocket-Key, and other headers. If the WebSocket handshake request is non-compliant, an error code will be returned and an internal WebSocket connection will be refused to be initiated to the OpenClaw core gateway (which only listens on 127.0.0.1 locally); If the WebSocket handshake request is compliant, an internal WebSocket connection to the OpenClaw core gateway is allowed.
[0040] S3: If the client is allowed to initiate an internal WebSocket connection with the OpenClaw core gateway, the security sandbox will initiate an internal WebSocket connection to the OpenClaw core gateway to transmit data, while performing real-time threat detection and handling.
[0041] After the security sandbox initiates an internal WebSocket connection to the OpenClaw core gateway, a bidirectional communication tunnel is formed, and all data between the client and the core gateway must pass through the security proxy.
[0042] Furthermore, the threat detection and handling includes the following steps: a) DPI Detection: The security sandbox parses each frame of data passing through the communication tunnel according to predefined DPI detection rules; DPI (Deep Packet Inspection) is an application-layer traffic analysis technique that not only examines network layer information such as IP headers and TCP headers, but also delves into the application-layer payload content of data packets to identify protocol types, data content, and behavioral characteristics. This allows the security sandbox to understand all the content transmitted within the internal WebSocket connection, rather than simply forwarding data blindly like a traditional gateway.
[0043] b) Signature matching: Detects whether the transmitted data contains malicious command injection, SQL injection, or other known attack signatures; Signature matching is a detection technique based on known threat signatures. It works by pre-building a malicious signature database (signature database), then comparing the content to be detected with the signatures in the database. If a match is found, the content is identified as malicious and blocked.
[0044] c) Behavioral analysis: Monitor the transmitted data for abnormal command sequences or unusually large data packets; d) Exception Handling: If abnormal behavior is detected in steps a)-c), perform the following operations according to the preset strategy: Immediately close the current internal WebSocket connection; Add the attack source IP or identifier to a temporary blacklist; Detailed attack logs are kept for post-incident analysis.
[0045] S4: If no threat is detected, the normal communication phase begins. The security sandbox forwards the transmitted data to the OpenClaw core gateway without modification. The OpenClaw core gateway performs business logic processing and sends the processing results back to the client through the security sandbox.
[0046] Furthermore, considering that introducing a security proxy layer inevitably introduces additional latency, the following optimization measures are taken to minimize the performance impact: 1) Use one of the compiled languages C++, Rust, or Go to develop the security agent to achieve near-native performance; 2) An event-driven, non-blocking I / O model is adopted to efficiently handle a large number of concurrent connections; 3) DPI detection uses an optimized string matching algorithm and a tailored regular expression engine to accelerate the signature detection process; 4) For DPI scenarios with encrypted traffic, utilize the CPU's AES-NI instruction set or a dedicated encryption / decryption hardware acceleration card to offload the TLS decryption load. 5) Compile the rules of high-level access control policies into lower-level, more efficient data structures or bytecode.
[0047] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.
[0048] The contents of this invention not described in detail are existing technologies known to those skilled in the art.
Claims
1. A method for resolving the OpenClaw hijacking problem via WebSocket based on a security sandbox, characterized in that, Includes the following steps; S1: Deploy the security agent and configure the security agent, OpenClaw core gateway, and hosts to build a security sandbox; S1 includes the following sub-steps: S11 Deploy security agent; Deploy the pre-built security agent on the same host or virtual machine running OpenClaw; The security agent is a standalone binary file or container image; S12 configures the network for the security agent; Configure the security agent to listen on the public network interface, using the port that OpenClaw originally used; S13 Configures policies for the security agent; Create and configure the security agent's policy file, defining a whitelist of legitimate Origin sources, DPI detection rules, and access control policies; S14 Modify the configuration file of the OpenClaw core gateway; Change the listening address in the OpenClaw core gateway configuration file from the port originally used by OpenClaw to the local loopback address or other local-access-only addresses and ports; S15 Configure the host's firewall rules; This ensures that only the local security agent process can access the port of the local loopback address, thereby enforcing isolation at the operating system level as well. With the above configuration, the security sandbox is finally built; S2: The client initiates a WebSocket handshake request to the OpenClaw core gateway. The security sandbox intercepts the WebSocket handshake request and verifies it. Based on the verification result, it decides whether to allow the client to initiate an internal WebSocket connection to the OpenClaw core gateway. S3: If the client is allowed to initiate an internal WebSocket connection with the OpenClaw core gateway, the security sandbox will initiate an internal WebSocket connection to the OpenClaw core gateway and transmit data, while performing real-time threat detection and handling. S4: If no threat is detected, the normal communication phase begins. The security sandbox forwards the transmitted data to the OpenClaw core gateway without modification. The OpenClaw core gateway performs business logic processing and sends the processing results back to the client through the security sandbox.
2. The method according to claim 1, characterized in that, Step S2 includes the following sub-steps: The S21 client initiates a WebSocket handshake request; The client attempts to connect to the default WebSocket control port address of the local AI agent; The S22 security sandbox first intercepts and captures WebSocket handshake requests; The S23 security sandbox performs origin verification on WebSocket handshake requests by checking the Origin field in the HTTP request header of the WebSocket handshake request. If the Origin field is not in the predefined whitelist, immediately return 403 Forbidden, blocking the internal WebSocket connection initiated by the client to the OpenClaw core gateway; If the Origin field is in the predefined whitelist, meaning the source is legitimate, further check whether the WebSocket handshake request complies with the RFC 6455 specification; If the WebSocket handshake request is non-compliant, an error code will be returned and the internal WebSocket connection to the OpenClaw core gateway will be refused. If the WebSocket handshake request is compliant, an internal WebSocket connection to the OpenClaw core gateway is allowed.
3. The method according to claim 1, characterized in that, The threat detection and handling in step S3 includes the following steps: a) DPI Detection: The security sandbox parses each frame of data passing through the communication tunnel according to predefined DPI detection rules; b) Signature matching: Detects whether the transmitted data contains malicious command injection, SQL injection, or other known attack signatures; c) Behavioral analysis: Monitor the transmitted data for abnormal command sequences or unusually large data packets; d) Exception Handling: If abnormal behavior is detected in steps a)-c), perform the following operations according to the preset strategy: Immediately close the current internal WebSocket connection; Add the attack source IP or identifier to a temporary blacklist; Detailed attack logs are kept for post-incident analysis.
4. The method according to claim 1, characterized in that, The following optimization measures were also adopted: 1) Use one of the compiled languages C++, Rust, or Go to develop the security agent to achieve near-native performance; 2) An event-driven, non-blocking I / O model is adopted to efficiently handle a large number of concurrent connections; 3) DPI detection uses an optimized string matching algorithm and a tailored regular expression engine to accelerate the signature detection process; 4) For DPI scenarios with encrypted traffic, utilize the CPU's AES-NI instruction set or a dedicated encryption / decryption hardware acceleration card to offload the TLS decryption load. 5) Compile the rules of high-level access control policies into lower-level, more efficient data structures or bytecode.