code

Home\Blog\

WebSocket Misconfigurations

Written by Yuval Donana on

WebSocket Misconfigurations

Written by Yuval Donana on


Introduction

WebSocket allows real-time communication between clients and servers. The WebSocket protocol was created in 2010 (RFC6455) to provide a low-overhead web protocol. It is gaining popularity as an essential component of web application development, where real-time communication is a key factor. However, despite its many benefits, the WebSocket protocol can pose significant security risks.

The WebSocket Protocol

WebSocket, operating at the application layer, enables full-duplex communication over a single, long-lived connection. Unlike HTTP, it avoids the request-response model and reduces overhead. Once connected, the client and server can exchange data in real time, making WebSocket ideal for online games, chat apps, and live data streams. To understand the protocol better, take an online chat application as an example. Without WebSocket, the application will have to make a request to the server every few seconds to receive new messages. With the WebSocket protocol, the server does not have to wait for a request from the client and can push the new message immediately. This means that WebSocket allows for faster and more efficient communication, making it well-suited for real-time applications where rapid data exchange is critical.

The Way a Connection is Made

To establish a WebSocket connection, the client sends an HTTP request to the server, including an Upgrade: WebSocket header indicating the will to upgrade to a WebSocket connection. The server responds with a Connection: Upgrade header to accept the upgrade. Once established, the client and server exchange data in real time using the WebSocket protocol.”

Common Attack Vectors

To gain a better understanding of how NoSQL queries work and where they can be vulnerable to injection attacks, let’s examine  MongoDB, the most popular NoSQL database. In the following example, we will utilize PHP to access MongoDB and demonstrate a simple example to implement authentication:

Misconfigurations in the WebSocket protocol could allow an adversary to perform a wide range of attacks against the application. Following is a comprehensive explanation of several commonly used attack vectors:

Advanced NoSQL Injection

Cross-Site WebSocket Hijacking (CSWH) is an attack that exploits the vulnerability of WebSocket to steal sensitive information. Because the initial connection uses HTTP, the client sends cookies scoped to the server’s domain with the upgrade request. Adversaries can exploit this behavior to perform unauthorized actions or fetch sensitive information.
For example, consider a live chat web application that responds with the user’s messaging history upon receiving a “GetHistory” message from the client. An adversary can host a web page that contains the following JavaScript code:

The above snippet will create a new WebSocket connection to example.com. Once the connection is made, a “GetHistory” message will be sent to the server.

When a user loads the example.com webpage, the JavaScript executes, and if the user’s cookies are valid, a connection establishes silently, allowing the attacker to access the victim’s sensitive data.

Mitigation

To mitigate this vulnerability, the WebSocket server should verify the authenticity of the connection, validating the origin of the HTTP request for an upgrade using the Origin header. A more resilient approach would be to apply a CSRF token. The token must be created on the server, randomly chosen, and impenetrable. The request must verify the token before performing any operation.

Denial Of Service (DOS)

When a client establishes a WebSocket connection with a server, it initiates a new TCP connection to the server. This protocol is built on top of the TCP protocol, and each WebSocket connection operates independently of other connections. Therefore, if a client needs to establish multiple WebSocket connections to a server, each connection will require a separate TCP connection. This can have a high impact on the server’s performance.
For example, consider an e-commerce website that uses WebSocket to provide real-time updates on product availability to its customers. An attacker who wants to disrupt the website’s operations launches a WebSocket DoS attack. The attacker creates a script that generates a large number of WebSocket connections to the e-commerce website’s server, overwhelming it with a large number of connections:

WebSocket

The above script initiates a new connection based on the provided argument. For example, 10,000 connections can be created simultaneously to the server. As the server attempts to handle all the incoming requests, it becomes overloaded and slows down. While the number of connections increases, the server eventually becomes unresponsive, and users can no longer access the system.

Mitigation

To mitigate WebSocket DoS risks, limit the data each user can send within a time frame, monitor and cap the server’s processing capacity, and restrict both per-user and total concurrent WebSocket connections. These measures prevent the server from becoming overwhelmed by excessive data and connections, reducing the likelihood of a DoS attack.

WebSocket Smuggling

Websocket smuggling is a type of attack that exploits the this protocol to bypass network security measures and gain unauthorized access to a server or a network. Even though the vulnerability does not originate from the said protocol, it is an integral part of the exploitation part.
To better understand the vulnerability, we need to understand how reverse proxies handle a WebSocket connection. The client establishes a connection by sending an HTTP upgrade request. Once the server responds with a ‘Switching Protocols’ status, the connection is active. Some reverse proxies skip checking this status, allowing attackers to trick the proxy into opening a TCP connection between the client and backend server, as shown below:

WebSocket
Direct TCP\TLS Connection Scheme to the Backend Server

This attack vector can be divided into the following steps:

  • The client sends an Upgrade request to the reverse proxy server with an intentionally wrong protocol version inside the Sec-WebSocket-Version header.
  • The proxy server fails to validate the header and assumes the Upgrade request is correct. It then forwards the request to the backend.
  • The backend responds with an HTTP 426 Upgrade Required status code because the protocol version is incorrect inside the Sec-WebSocket-Version header. However, the reverse proxy server does not check the response completely from the backend, including the status code, and assumes that the backend is ready for WebSocket communication.
  • The proxy then forwards the request back to the client. At this point, the reverse proxy assumes a WebSocket connection exists between the client and backend, even though the backend refused the Upgrade request.
  • The proxy server keeps the TCP or TLS connection (between the client and the server) open. The adversary is able to access the private REST API by sending an HTTP request over the open connection.
  • The proxy server will forward the request to the backend, which will respond as if the request came from a legitimate client.

Mitigation

To prevent this type of attack, it is essential to implement strict WebSocket protocol parsers on the server side and to configure the reverse proxy server to reject it’s messages that do not comply with the WebSocket protocol specification. Additionally, configure the reverse proxy to validate all backend responses, including status codes, to prevent misinterpreting the backend’s intent.

References