Cross-Site WebSocket Hijacking: Step-by-Step Attack Mechanics
WebSocket connections often bypass same-origin policy protections, allowing attackers to hijack active sessions if authentication tokens are stored in cookies without proper restrictions.
Cross-site WebSocket hijacking occurs when an attacker forces a victim’s browser to open a WebSocket connection to a target server. If the connection relies on cookies for authentication and lacks anti-CSRF tokens, the server treats the attacker’s connection as the victim’s, leaking real-time data or executing actions on their behalf.
The Protocol Upgrade Mechanism
WebSockets provide full-duplex communication channels over a single TCP connection. Unlike traditional HTTP requests, which are stateless and request-response based, WebSockets maintain a persistent link. This persistence allows servers to push data to clients in real time. The connection begins with an HTTP handshake. The client sends an HTTP GET request with specific headers indicating the intent to upgrade the protocol. If the server agrees, it responds with a status code 101 Switching Protocols. Once upgraded, the connection remains open until either party closes it.
This upgrade process is the critical window for exploitation. The handshake uses standard HTTP methods. This means it behaves like any other HTTP request regarding authentication and origin checks. If the server relies on cookies for identity verification during this handshake, it exposes a significant attack surface. The server assumes the request originated from the same domain that set the cookies. This assumption is often incorrect in the presence of cross-site scripting or other injection flaws.
The Authentication Dependency
Most web applications use cookies to manage user sessions. These cookies are sent automatically with every request to the domain that set them. This convenience creates a vulnerability when the application does not validate the source of the request. The server sees the valid session cookie and assumes the request is legitimate. It does not inherently know where the request originated. The browser sends the cookie regardless of whether the request came from the application’s own pages or a malicious site.
This behavior is known as implicit authentication. The application trusts the presence of the cookie rather than verifying the context of the request. For WebSocket connections, this is particularly dangerous because the handshake is a simple GET request. Attackers can trigger these requests from any context they control. If the server does not check the Origin or Referer headers during the handshake, it cannot distinguish between a legitimate user and an attacker. The connection is established with the victim’s credentials.
Stage 1: The Malicious Page
Imagine a user visits a seemingly harmless website. This site contains a hidden script that initiates a WebSocket connection to a target application. The script specifies the target’s WebSocket endpoint URL. The user’s browser processes this request. It checks for any cookies associated with the target domain. If the user is logged into the target application in the same browser, those cookies are present. The browser attaches these cookies to the WebSocket handshake request. The user is unaware that their browser is communicating with a third-party service.
Stage 2: The Handshake Exploitation
The target server receives the handshake request. It sees the valid session cookie. It does not verify the Origin header. It accepts the request and upgrades the connection. The server now believes it is talking to the legitimate user. It opens a bidirectional channel. The attacker’s script on the malicious page now controls this channel. The attacker can send messages to the server and receive messages from it. The server routes these messages as if they came from the victim’s authenticated session.
Stage 3: Data Exfiltration or Action
With the connection established, the attacker can exploit the real-time nature of WebSockets. If the application pushes sensitive data, such as chat messages or financial updates, the attacker intercepts this data. The attacker receives the data in their browser context. They can then send this data to their own server for exfiltration. Alternatively, if the application allows commands via WebSocket, the attacker can inject malicious commands. These commands execute with the victim’s privileges. The damage occurs without the victim leaving the malicious page.
| Stage | What happens | Where it can be stopped |
|---|---|---|
| Stage 1 | Attacker’s page triggers WS connection | User awareness or browser extensions blocking mixed content |
| Stage 2 | Server accepts handshake without origin check | Server-side Origin/Referer validation or SameSite cookie attributes |
| Stage 3 | Attacker reads/writes session data | Application logic binding WS sessions to unique tokens, not cookies |
The Failure of Standard Defenses
Standard CSRF protections often fail against WebSocket hijacking. CSRF tokens are typically embedded in HTML forms or HTTP headers. The WebSocket handshake is a GET request with limited header options. It does not easily support custom headers required for token validation. Attackers can bypass these checks by simply omitting the token. The server, seeing no token, might default to cookie-based authentication. This fallback creates a gap in security.
Another common misconception is that Same-Origin Policy (SOP) protects WebSocket connections. SOP restricts how documents or scripts loaded from one origin can interact with resources from another origin. However, the WebSocket API allows connections to any origin. The browser does not block the connection attempt. It only restricts the JavaScript from reading the response if the connection fails or is blocked by CORS. Since the connection succeeds and the server accepts the cookie, the data flows freely. The SOP does not inspect the content of the WebSocket frames.
Mitigation Strategies for Developers
Developers must implement explicit origin validation during the WebSocket handshake. The server should check the Origin header against a whitelist of trusted domains. If the Origin header is missing or does not match, the server must reject the handshake. This prevents unauthorized domains from establishing connections. However, this method can be fragile. Some proxies strip Origin headers. Users behind certain corporate networks may have modified headers. Relying solely on Origin checks can lead to false positives or security regression testing failures.
A more robust approach is to decouple WebSocket authentication from cookies. The application should issue a unique, opaque token for each WebSocket session. This token is generated after the initial HTTP authentication. The client must include this token in the WebSocket handshake, typically as a query parameter or in a specific header. Since this token is not stored in cookies, it is not sent automatically by the browser. The attacker’s script cannot access this token due to SOP restrictions on reading the token from the legitimate application’s page. This breaks the chain of exploitation.
The Hidden Cost of Persistence
WebSocket connections remain open for long periods. This persistence means that once hijacked, the attacker has a sustained foothold. They do not need to re-authenticate. They can monitor activity in real time. This makes detection difficult. Traditional intrusion detection systems look for anomalous traffic volumes or known attack signatures. A hijacked WebSocket connection looks like normal, low-volume traffic. The data flow is consistent with legitimate usage.
This stealthiness increases the window of exposure. The attacker can wait for sensitive information to appear. They can also perform slow, low-and-slow attacks that do not trigger rate-limiting alarms. The connection remains active until the user closes their browser or the server times out. This duration is often hours or days. The longer the connection stays open, the more data the attacker can collect.
Integrating with Security Workflows
Addressing this vulnerability requires more than just code changes. It requires integration into the development lifecycle. Security regression testing should include specific test cases for WebSocket hijacking. These tests verify that unauthorized origins are rejected and that tokens are required. Automated vulnerability scanning tools may not detect this flaw. They often check for common SQL injection or XSS issues. WebSocket-specific logic requires manual review or specialized testing scripts.
Developers should also consider the impact on browser updates. New browser versions may change how cookies or headers are handled. Features like SameSite cookie attributes can mitigate some risks by preventing cross-site cookie sending. However, these features are not universally supported in all environments. They should be used as a defense-in-depth measure, not a sole solution. Understanding attack vectors in CVSS helps prioritize this risk. While not always critical, the ease of exploitation and impact on confidentiality can elevate its severity.
Key takeaways
- WebSocket connections inherit HTTP cookies, making them vulnerable to hijacking if the origin is not validated server-side.
- Standard CSRF tokens are often insufficient for WebSocket upgrades because the handshake is a simple HTTP GET request.
- Mitigation requires strict origin validation or binding the WebSocket session to a unique, opaque token rather than cookies.
WebSocket hijacking exploits the automatic sending of cookies during protocol upgrades, bypassing standard origin checks. Implement server-side origin validation and bind WebSocket sessions to unique, non-cookie tokens to prevent unauthorized access.
Frequently asked questions
Can CORS headers prevent WebSocket hijacking?
No, CORS headers control JavaScript access to responses, not the establishment of the connection itself. The server still accepts the cookie during the handshake.
Do SameSite cookies stop this attack?
SameSite=Strict or SameSite=Lax can prevent cookies from being sent in cross-site requests, effectively mitigating this specific attack vector.
Is this the same as Cross-Site Scripting?
No, XSS involves injecting malicious scripts into web pages. WebSocket hijacking exploits the protocol’s authentication mechanism, often without any script injection on the target site.
How do I test for this vulnerability?
Use a browser extension or proxy to modify the Origin header of a WebSocket handshake. If the server accepts the connection with a valid cookie but an invalid origin, it is vulnerable.
How this guide was produced: written by the BlueTeam Herald editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
