- Security
- A
Inspection of the WebSocket protocol using the Solar webProxy proxy server
The WebSocket protocol allows for the establishment of a permanent two-way connection between the client and the server, which significantly reduces latency and decreases the amount of data transmitted compared to traditional HTTP requests.
WebSocket is used in dynamically updating applications that operate in real-time, such as messengers, trading platforms, and other commercial services with rapidly changing data. Thanks to the correct filtering rules of the WebSocket protocol, such traffic can be recognized and, if necessary, blocked.
My name is Alexander Lemaev, I am a lead analyst in the Solar webProxy team. Solar webProxy is a Secure Web Gateway (SWG) that controls access to web resources, protects against infected and phishing sites, and blocks leaks through the web channel. In this article, I will explain the advantages of WebSocket and how our Solar webProxy proxy server helps filter this protocol.
What is the WebSocket protocol and how it simplifies client-server interaction
The WebSocket data transfer protocol allows for low-latency, real-time, bidirectional, full-duplex communication between the client and the server. Unlike the traditional HTTP protocol, WebSocket can operate asynchronously. That is, the client and server can send data to each other without continuous or preliminary polling. Also, WebSocket is stable in the presence of interference—if they occur, the connection does not need to be re-established. As soon as the connection is restored, the data will be transmitted.
WebSocket operates on top of the TCP transport protocol. HTTP is used to establish a WebSocket connection, and the process itself is called a WebSocket Handshake. The ws:// or wss:// schemes are used for connection, which are similar to the http:// and https:// schemes.
The request for connecting to the server via WebSocket from the client looks like this:
The server's response to the client's request looks like this:
The client expects to see in the response: HTTP 101 Switching Protocols. This means that the server is switching to the protocol requested by the client — that is, WebSocket.
There are several typical scenarios where it is advisable to use the WebSocket protocol, for example:
Real-time updates. Thanks to this, WebSocket is ideal for resources where instant information updates are important — for example, trading or banking applications. Users will be able to follow the information online without constantly reloading the application page.
High-frequency data transmission. WebSocket can be used for messengers, streaming services, video conferences, social network chats — anywhere where data transfer speed is important.
Synchronization. WebSocket allows multiple users to simultaneously edit an online document — the changes made are displayed instantly. The protocol also helps track the time of each adjustment and watch colleagues' work in real-time.
HTTP vs WebSocket
HTTP and WebSocket are similar in function but serve different purposes and differ in their operating principles.
Characteristic | HTTP | WebSocket |
Interaction Model | Unidirectional: | Full-duplex (bidirectional). Supports asynchronous mode — client and server can send data to each other at any time. |
Security and Encryption | The address of the unencrypted version starts with http://, the encrypted one starts with https:// | The address of the unencrypted version starts with ws://, the encrypted one starts with wss:// + uses data masking |
Caching | Only static data to speed up response sending | Does not support caching — only real-time updates |
Transport | Works with TCP, but starting from HTTP3, uses UDP protocol for acceleration (QUIC) | Supports only TCP, as the protocol requires stability |
Latency | Each request requires a new handshake and header negotiation — that is, latency is higher than WebSocket | No need for frequent handshakes, header negotiations, and long polling. Messages are sent using frames without headers, as the connection is not interrupted — that is, latency is lower than HTTP |
Connection Duration | A new connection is required for each request. The connection lasts until the request-response is received | Supports persistent connection with instant data transfer without constant request-response cycles |
Binary Data Support | By default, only text data is supported. To process binary data, support for additional protocols or encoding (e.g., Base64) is needed | Supports binary data natively — multimedia content can be transferred quickly |
Security Issues of the WebSocket Protocol
Despite the advantages over HTTP, developers have mixed feelings about WebSocket. Transmitting data without closing the connection after a request or response makes the information vulnerable to hackers. For example, early versions of the protocol were subject to a "Cache Poisoning" attack, which targeted caching proxy servers.
How the "Cache Poisoning" Attack Occurred The attacker invited the client to visit a fraudulent web page that established a WebSocket connection with the hacker's site. It was assumed that the victim was behind a proxy server. The hacker's page formed a WebSocket request to send a message to the attacker's server. The proxy server allowed it, waiting for the next request for an HTTP connection. But in reality, the connection was not interrupted and continued to work through WebSocket. Both ends of the open connection were controlled by the hacker, who could freely transmit malicious data through it. Since the proxy server cached this data, each of its users received the hacker's code instead of the real jQuery code. |
The risk of a "Cache Poisoning" attack was initially theoretical, but an analysis of WebSocket vulnerabilities showed that it could indeed happen. Then the protocol developers introduced data masking, which is successfully used to protect both sides of the connection. The data is encrypted using a randomly generated 4-byte value (key) with a predefined algorithm.
What other attacks can affect WebSocket:
Cross-site hijacking — one of the scenarios of cross-site request forgery (CSRF). The attack is possible when the handshake for the WebSocket connection occurs through HTTP cookies without using CSRF tokens or similar security measures.
Injection attacks — the introduction of malicious code into a vulnerable application. This is one of the most common attacks on the HTTP protocol, but it is also applicable to WebSocket. The most popular are SQL injections, where hackers manipulate queries when working with databases, as well as cross-site scripting (XSS), where malicious scripts are injected into web pages.
Denial of Service (DOS) — an attack on a web server that supports WebSocket. The attacker sends a large number of requests to the server, causing it to crash or reboot. Common attacks of this class are WebSocket Flood, WebSocket Ping Pong, WebSocket Slowloris. Read more here.
WebSocket Smuggling — this attack allows a hacker to bypass the restrictions of reverse proxy servers, making them believe that a WebSocket connection has been established (even if it has not). Read more here.
One way to prevent these attacks is to filter WebSocket traffic using the Solar webProxy proxy server.
How to filter WebSocket using Solar webProxy
In version 4.1 of Solar webProxy, it became possible to filter WebSocket. To do this, go to the "Policy" section, then to the "Content Filtering" subsection, then to the "Request Filtering" layer when creating rules and exceptions, and here in the advanced settings you can select WebSocket and WebSocket Secure.
It is allowed to choose WebSocket and/or WebSocket Secure protocols in the Response Filtering layer, but then Solar webProxy will filter responses, expecting “101 Switching Protocols” from the application server.
In previous versions of the product, it was not possible to select WebSocket or WebSocket Secure in the “Request Filtering” and “Response Filtering” layers. The available protocols were only HTTP, HTTPS, and/or FTP (over HTTP).
Example of blocking the WebSocket protocol for the BitMEX cryptocurrency exchange platform:
How to notify the user about WebSocket blocking
If the administrator wants to notify the user about the intentional blocking of WebSocket, they can create rules in the request or response filtering layers:
Rule for blocking the WebSocket/WebSocket Secure protocol;
Rule for user notifications.
If the administrator does not plan to block WebSocket but wants to warn the user about protocol malfunctions on the web resource side, they can create a rule to display a JavaScript banner for the user — without blocking rules for WebSocket in the layer.
When receiving the banner, some resource functions will be unavailable, for example:
real-time information updates;
chat messaging;
connecting to streams or conferences.
The banner will appear when the WebSocket protocol is initialized, intercepted in the main thread. Therefore, if you close the banner, it will appear again, as some elements of the page will not be loaded.
How to create conditions for filtering the WebSocket protocol in Solar webProxy
All interactions between clients and servers within WebSocket connections occur using frames — small headers with many bits and "payload". The payload is all application data, similar to the body of an HTTP message.
The frame looks like this:
Frames are divided into two types:
with data (non-control frames);
for control (control frames) — they are needed to check and close the connection.
Messages between the client and the server are fragmented — that is, one message can be split into several data frames. Within a WebSocket connection, a control frame can be in the middle of a fragmented message, but it is not allowed to send a frame with extraneous data in one of the fragments. Fragmentation of control frames is not possible, and the payload must be less than 125 bytes. A full description of the protocol and fields is contained in RFC 6455.
In Solar webProxy 4.1, in the "Request Filtering" and "Response Filtering" layers, you can create rules and exceptions with additional conditions for headers, types and file sizes, keywords. But each condition has its own complexities:
The format of the description of headers in Solar webProxy is more characteristic of HTTP headers. It is not entirely clear how to designate this "header" for frames, as it represents a set of fields with values;
Files transmitted via WebSocket are likely to be fragmented. It is difficult to understand the type and size of the file from the "pieces". But you can pay attention to the "FIN" and "Opcode" bits.
The "Keywords" attribute allows you to select words and their weight and set the trigger threshold. But when data is fragmented, it will not be possible to correctly filter messages, as the keywords will also be fragmented.
An additional complexity is data masking, which protects against hacker attacks, as it encrypts the content, and the keywords are difficult to recognize.
Further developments in WebSocket filtering
In Solar webProxy, data filtering (HTTP, HTTPS, HTTP over FTP) is handled by the skvt-wizor service. After establishing a WebSocket connection between the client and the server, we plan to download all frames to obtain complete messages. We will determine the beginning and end of messages using the "FIN" and "Opcode" bits. If the message consists of a single frame, we will check its content. If the message is fragmented, we will record each frame as a separate file for further verification.
The result of the check will depend on the configured policy in content filtering. A full check will include MIME type detection, metadata and text extraction, object scanning on the ICAP server (antivirus, sandbox, or DLP system), and filtering based on conditions in rules/exceptions — for example, by keywords or file size.
In Solar webProxy, each frame will have its own implementation of the intra-object entity, which will determine:
the necessity of caching the object to disk or storing it in RAM;
the necessity of unpacking — if compression is applied;
the necessity of transferring data to filtering nodes — if object checking is required.
We will extract the mask from the frame metadata, then unmask the payload by writing the obtained data into the Solar webProxy object entity.
Conclusion
WebSocket protocol filtering by frames is still under investigation. Most likely, we will make changes to the future implementation of this feature, but for now, we decided to share it as we did not find other practical solutions for WebSocket frame filtering.
Thank you for your attention to the article! I will be glad to receive comments and feedback.
Write comment