Today, many leading industries and modern enterprises have switched from processing and acting on data stored in databases to data in flight. How? Through real-time applications. One way to enable this is WebSocket, but it comes with vulnerabilities as well.

What is WebSocket?

Real-time applications operate within an immediate time frame; sensing, analyzing and acting on streaming data as it happens. With real-time applications, you need information from your servers as soon as it is available.

WebSocket is a network protocol built on the Transmission Control Protocol, designed to make use of a more modern connection to receive and send ongoing real-time messages as required.

More and more end-users and business leaders today call for real-time experiences to remain competitive.

Before WebSocket came along, the ‘real-time’ web existed, but it was difficult to achieve since the web is built on the HTTP protocol paradigm. HTTP is stateless: there is no link between two requests successively carried out on the same connection. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests.

Let’s take a look at how it works, how attackers can exploit it and how to defend against those techniques.

How does WebSocket work?

Sockets connect two services formed by a mix of IP and a port. They act as a unique, programmatic way to receive and send data and are key to network applications everywhere.

WebSocket connections start over HTTP and are often long-lived. Messages can be sent in either direction at any time and are not transactional in nature.

WebSocket handshake

To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The life cycle of a WebSocket interaction between client and server includes the following steps:

  • A client initiates a connection to the server by sending an HTTP(S) WebSocket handshake request
  • The server replies with a handshake response that consists of an HTTP response with a status code of 101 switching protocols (and a number of specific HTTP headers) to accept the WebSocket handshake
  • The server can then send messages directly to the client without a client initiation of requests
  • The client can explicitly (or via timeout) close the WebSocket connection.

 Browser Request

GET /message HTTP/1.1

Host: message-websocket.com

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==

Connection: keep-alive, Upgrade

Cookie: session= <sessionid>

Upgrade: websocket

Server Response

HTTP/1.1 101 Switching Protocols

Connection: Upgrade

Upgrade: websocket

Sec-WebSocket-Accept: 0FFP+2nmNIf/h+4BP36k9uzrYGk=

The WebSocket handshake headers

You should also be aware of headers. These provide context and explanations about the connection. 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.

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 the Sec-WebSocket-Key request header.

Cross-site WebSocket vulnerability

One key thing to look out for is the cross-site WebSocket vulnerability (also known as cross-origin WebSocket hijacking). It involves a cross-site request forgery (CSRF) on a WebSocket handshake. The WebSocket protocol itself does not prescribe any particular way that servers can authenticate clients during the WebSocket handshake over HTTP.

For example, in the below request, the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any tokens in request parameters. This request is probably at risk for CSRF.

GET /message HTTP/1.1

Host: message-websocket.com

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: wDqumtseNBJdhkihL6PW7w==

Connection: keep-alive, Upgrade

Cookie: session=KOsEJNuflw4Rd9BDNrVmvwBF9rEijeE2

Upgrade: websocket

Hence, the first step to performing an attack is to review the WebSocket handshakes and determine whether they have protection against CSRF.

How to identify a cross-site WebSocket vulnerability

In a vulnerable Live chat application created using WebSocket, a threat actor uses the exploit server to host an HTML/JavaScript payload. This takes advantage of the at-risk WebSocket handshake request since the only session token is transmitted in a cookie. From here, the threat actor can exfiltrate the victim’s chat history.

Step 1: Access the Live chat feature and send the first text message.

( Hi, I am vulnerable to cross-site WebSocket hijacking)

Step 2: Capture the WebSocket handshake request with the help of the HTTP proxy tool and observe the request. The only session token present is in the cookie header.

Note: The Sec-WebSocket-Key header contains a random value to prevent errors from caching proxies and is not related to authentication or session handling purposes.

Step 3: Host an HTML payload with the WebSocket handshake URL to exfiltrate the victim’s chat history using the external service interaction.

Step 4: Once the victim clicks the malicious URL via a phishing email or through a random ad on a webpage, the threat actor can retrieve the chat history of the victim and exfiltrate it via external service interaction. The request body contains the full contents of the chat message in the JSON format.

Testing cross-site WebSocket hijacking via an automated tool

Defenders can spot cross-site WebSocket hijacking with a Python tool found on GitHub. Below are the steps to see if your application is at risk for cross-site WebSocket hijacking.

GitHub link: https://github.com/DeepakPawar95/cswsh.git

Step 1: Download the Python code via Git clone.

Step 2: Install dependencies via Pip.

<pip3 install click pyfiglet Figlet websockets requests>

Step 3: Run the Python script by providing the WebSocket URL.

How to fix and prevent cross-site WebSocket hijacking

To prevent attackers from doing this, ensure any applications connect to the WebSocket server over a secure TLS connection. You will also need to be sure to properly configure the server to verify and validate the contents of the ‘origin’ header received from the client over HTTP in its WebSocket handshake initiation request.

Same-site attributes on the session cookie can also be useful. These will instruct the browser not to send the cookie on any cross-origin request.

Last but not least, implement CSRF tokens on every request handling WebSockets. CSRF tokens include an unpredictable value (token), which is uniquely bound to the user’s session in page. Generate CSRF tokens on the server side. You can do this once per user session or for each request. This way, you can take advantage of WebSocket while cutting off an avenue for attackers.

More from Data Protection

3 Strategies to overcome data security challenges in 2024

3 min read - There are over 17 billion internet-connected devices in the world — and experts expect that number will surge to almost 30 billion by 2030.This rapidly growing digital ecosystem makes it increasingly challenging to protect people’s privacy. Attackers only need to be right once to seize databases of personally identifiable information (PII), including payment card information, addresses, phone numbers and Social Security numbers.In addition to the ever-present cybersecurity threats, data security teams must consider the growing list of data compliance laws…

How data residency impacts security and compliance

3 min read - Every piece of your organization’s data is stored in a physical location. Even data stored in a cloud environment lives in a physical location on the virtual server. However, the data may not be in the location you expect, especially if your company uses multiple cloud providers. The data you are trying to protect may be stored literally across the world from where you sit right now or even in multiple locations at the same time. And if you don’t…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today