websockets
The
Connection
andUpgrade
headers in the request and response indicate that this is a WebSocket handshake.The
Sec-WebSocket-Version
request header specifies the WebSocket protocol version that the client wishes to use. This is typically13
.The
Sec-WebSocket-Key
request header contains a Base64-encoded random value, which should be randomly generated in each handshake request.The
Sec-WebSocket-Accept
response header contains a hash of the value submitted in theSec-WebSocket-Key
request header, concatenated with a specific string defined in the protocol specification. This is done to prevent misleading responses resulting from misconfigured servers or caching proxies.
User-supplied input transmitted to the server might be processed in unsafe ways, leading to vulnerabilities such as SQL injection or XML external entity injection.
Some blind vulnerabilities reached via WebSockets might only be detectable using out-of-band (OAST) techniques.
If attacker-controlled data is transmitted via WebSockets to other application users, then it might lead to XSS or other client-side vulnerabilities.
Manipulate WS handshake
Some WebSockets vulnerabilities can only be found and exploited by manipulating the WebSocket handshake. These vulnerabilities tend to involve design flaws, such as:
Misplaced trust in HTTP headers to perform security decisions, such as the
X-Forwarded-For
header.Flaws in session handling mechanisms, since the session context in which WebSocket messages are processed is generally determined by the session context of the handshake message.
Attack surface introduced by custom HTTP headers used by the application.
XSS in message
{"message":"Hello Carlos"}
The contents of the message are transmitted (again via WebSockets) to another chat user, and rendered in the user's browser as follows:
<td>Hello Carlos</td>
In this situation, provided no other input processing or defenses are in play, an attacker can perform a proof-of-concept XSS attack by submitting the following WebSocket message:
{"message":"<img src=1 onerror='alert(1)'>"}
CSWSH
Cross-Site WebSocket Hijacking (CSWSH) Summary:
Definition:
CSWSH is a cross-site request forgery (CSRF) vulnerability involving the WebSocket handshake.
It occurs when WebSocket handshakes rely solely on HTTP cookies for session handling, without CSRF tokens or other unpredictable values.
An attacker can exploit this by creating a malicious webpage that establishes a WebSocket connection using the victim’s session.
How the attack works:
The attacker’s page initiates a WebSocket connection with the vulnerable application.
The application processes this connection in the victim's session context.
The attacker can send arbitrary messages to the server and read responses, enabling two-way interaction.
Impact:
Unauthorized actions: The attacker can perform actions as the victim by sending messages via WebSocket.
Data theft: The attacker can intercept and read sensitive data sent back from the server, which is not possible in typical CSRF attacks.
Performing the attack:
The attacker reviews WebSocket handshakes to check if they rely solely on HTTP cookies, without CSRF protections (e.g., tokens).
An example of a vulnerable handshake is a WebSocket request where the session token is only in a cookie.
If the handshake is vulnerable, the attacker can:
Send WebSocket messages to trigger unauthorized actions.
Intercept sensitive data sent by the server.
Wait for sensitive data to be sent from the application over WebSocket.
Script for open new ws connection
Change wss and collaborator-url.
ws.send message to first message of websocket
Last updated