Getting Started with Web Socket Pentesting

5 min readNov 20, 2020

What is/are WebSockets?

WebSockets is a bi-directional, full-duplex communications protocol initiated over HTTP. They are commonly used in modern web applications for streaming data, Chat applications, and other asynchronous traffic. It is a protocol where the client and server can send the messages simultaneously over the channel.

What is the main difference between WebSocket and normal HTTP Communication?

HTTP is a half-duplex stateless protocol where the client sends a request to the server and then waits for the server’s response whereas, in the WebSockets, it is a full-duplex stateless protocol that is initiated over HTTP and is long-lived.It doesn’t wait for the server to respond back, instead, the client can send any number of requests to the server.

WebSockets are preferred in the application which requires low latency communication.

How the WebSocket handshake is done and related security issues?

WebSocket connections are normally created using client-side JavaScript like the following:

var ws = new WebSocket("wss://normal-website.com/chat");

To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The browser issues a WebSocket handshake request like the following:

GET /chat HTTP/1.1 Host: normal-website.com Sec-WebSocket-Version: 13 Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w== Connection: keep-alive, Upgrade Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2 Upgrade: websocket

If the server accepts the connection, it returns a WebSocket handshake response like the following:

HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: websocket Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

At this point, the network connection remains open and can be used to send WebSocket messages in either direction.

Issues and Observations :

The Connection and Upgrade 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 typically 13 and is not a vulnerable parameter
The Sec-WebSocket-Key request header contains a Base64-encoded random value, which should be randomly generated in each handshake request. This header is not the one which uniquely identifies a user or can be used for authorization purposes
The Sec-WebSocket-Accept response header contains a hash of the value submitted in the Sec-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.
The wss protocol establishes a WebSocket over an encrypted TLS connection, while the ws protocol uses an unencrypted connection. So if the server is accepting connections from ws protocol it is vulnerable to MITM attacks.
This protocol doesn’t prescribe any particular way that the servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client mechanism available to a generic HTTP server, such as Cookies, HTTP authentication, or TLS authentication.
WebSockets does not follow same-origin-policies

How to Intercept and modify WebSocket messages

You can use Burp Proxy to intercept and modify WebSocket messages, as follows:

Configure your browser to use Burp Suite as its proxy server.
Browse to the application function that uses WebSockets. You can determine that WebSockets are being used by using the application and looking for entries appearing in the WebSockets history tab within Burp Proxy.
In the Intercept tab of Burp Proxy, ensure that interception is turned on.
When a WebSocket message is sent from the browser or server, it will be displayed in the Intercept tab for you to view or modify. Press the Forward button to forward the message.
The WebSockets messages can be seen in WebSocket history, where you can see all the requests and responses that have taken so far with the server.
If you wish to replay any message you can simply just send the particular message from the history to the repeater.

Common Vulnerabilities associated with WebSockets

Origin Verification → It is the server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the server does not validate the origin header in the initial WebSocket handshake, the WebSocket server may accept connections from any origin. This could allow attackers to communicate with the WebSocket server cross-domain allowing for CSRF-like issues.
Most Chat applications which are using WebSockets are vulnerable to XSS because the input sanitization is not implemented properly by the application and it trusts the user input
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.
Most applications are vulnerable to IDOR and authorization issues as there is no header in WebSocket which can check for such issues.
WebSockets let an unlimited number of connections reach the server. This lets an attacker flood the server with a DOS attack. This greatly strains the server and exhausts the resources on that server. Then the website slows down greatly.
The most widely found vulnerability in WebSocket is Cross-Site WebSocket Hijacking

Cross-Site WebSocket Hijacking(CSWSH)

A Cross-Site WebSocket Hijacking attack is essentially a CSRF on a WebSocket handshake.

When a user is logged into victim.com in her browser and opens attacker.com in the same browser, attacker.com can try to establish a WebSocket connection to the server of victim.com. Since the user’s browser would automatically send over her credentials with any HTTP/ HTTPS request to victim.com, the WebSocket handshake request initiated by attacker.com would contain the user’s legitimate credentials. This means the resulting WebSocket connection (created by attacker.com) would have the same level of access as if it originated from vicitm.com.

After the WebSocket connection is established, attacker.com can communicate directly to victim.com as a legitimate user.

Structure of an attack

To carry out the attack, an attacker would create a script that will initiate the WebSocket connection to the victim server. She can then embed that script on a malicious page and trick a user into accessing the page.

When the victim accesses the malicious page, her browser will automatically include her cookies into the WebSocket handshake request (since it’s a regular HTTP request). The malicious script crafted by the attacker will now have access to a WebSocket connection created using the victim’s credentials.

The impact of Cross-Site WebSocket Hijacking

Using a hijacked WebSocket connection, the attacker can now achieve a lot of things:

WebSocket CSRF: If the WebSocket communication is used to carry out sensitive, state-changing actions, attackers can use this connection to forge actions on behalf of the user. For example, attackers can post fake messages onto a user’s chat groups.
Private data retrieval: If the WebSocket communication can be used to retrieve sensitive information via a client request, attackers can initiate fake requests to retrieve sensitive data belonging to the user.
Private data leaks via server messages: Attackers can also simply listen in on server messages and passively collect information leaked from these messages. For example, an attacker can use the connection to eavesdrop on a user’s incoming notifications.