1.3 Differences between WebSocket and HTTP

1. WebSocket protocol

1.1 Introduction

WebSocket protocol is a new network protocol based on TCP. It implements full-duplex (full-duplex) communication between the client and the server, allowing the server to actively send information to the client. Therefore, in WebSocket, the client and the server only need to complete one handshake, and a persistent connection can be established between them directly, and bidirectional data transmission can be carried out, making data exchange between the client and the server simpler.

1.2 Characteristics

The characteristics of WebSocket are as follows:

• Less control overhead. After the connection is established, the data packets with protocol control information exchanged between the server and the client are relatively smaller. Without extensions, the header size for content from the server to the client is only 2 to 10 bytes (related to the packet length); for content from the client to the server, an additional 4-byte mask is also needed.

• Stronger real-time performance. Since the protocol is full-duplex, the server can send data to the client at any time.

• Maintain connection status. Unlike HTTP, Websocket needs to establish a connection first, making it a stateful protocol that can omit some status information during communication. HTTP requests may need to carry status information (such as authentication) with each request.

• Better binary support. Websocket defines binary frames, which can handle binary content more easily than HTTP.

• Support for extensions. Websocket defines extensions, allowing users to extend the protocol and implement partially customized subprotocols.

• Better compression effect. Compared to HTTP compression, Websocket can maintain the context of the previous content under appropriate expansion support, and can significantly improve the compression rate when transmitting similar data.

1.3 Differences between WebSocket and HTTP

• HTTP is a stateless protocol that allows clients to request resources from the server and receive responses from the server. Clients use the HTTP request/response syntax, that is, after the request is sent to the server, the server returns HTML files, images, and other media content to the client.

• The WebSocket communication protocol tries to improve web real-time communication and plug-in technology over a wider range, and provides full-duplex, event-based communication without using inefficient polling methods. Developers can easily create WebSocket connections and send data from the JS end of the Web browser, thus realizing the implementation of real-time data transmission in applications.

• Since WebSocket is message-oriented, it is more suitable for real-time communication, while HTTP is more suitable for request and server-client communication responses.

2. WebSocket API

Websocket uses a unified resource identifier (URI) of ws or wss, where wss indicates that TLS is used for Websocket, similar to the http and https of the HTTP protocol. The wss protocol establishes a WebSocket through a TLS connection, which is encrypted transmission; the ws protocol is plaintext transmission.

• ws://echo.websocket.org
• wss://echo.websocket.org

Like traditional APIs, the WebSocket API is composed of elements such as communication protocols, domain names, version numbers, paths, and request parameters. However, due to the fact that the WebSocket API creates a persistent connection between the client and server after completing the handshake process, and can directly communicate with data interactions using text messages or binary messages, the traffic messages we generally see in the WebSocket API are usually JSON format text messages.

From the perspective of development, the WebSocket API also includes:

• Constructor, the syntax example of the constructor is: const myWebSocket = new WebSocket(url [, protocols]), where url represents the URL of the connection; protocols represents a protocol string or an array of protocol strings, which is optional.

• Properties: The properties are divided into many, mainly including bufferedAmount, which represents the number of bytes not sent to the server; onopen, which specifies the callback function after the connection is successful, and so on.

• Method: The methods are mainly divided into close and send, which represent closing the WebSocket connection and sending data to the server, respectively.

• Event: The events mainly include close, error, message, and open.

3. Business Scenarios of WebSocket API

As an important client-server communication interface, WebSocket API can be used in which business scenarios? It is mainly divided into three categories:

• Applications with real-time data updates: For applications that require the server to continuously send data to be displayed in real time on the client, using WebSocket API as the data transmission interface is undoubtedly the best choice.

• Game applications: In game applications, the general scenario is that the server needs to continuously receive data without refreshing the UI. The data transmitted will take effect on the screen, and the UI will also refresh automatically without the need to establish a new connection.

• Chat applications: Chat applications generally have a long connection status to facilitate real-time communication between users. Using WebSocket API only requires a single connection to achieve one-to-one message transmission and maintain a long-term communication connection.

Specific business scenarios are listed:

4. Security Risks of WebSocket API

The security risks of WebSocket API are mainly divided into two categories: common attack risks and specific attack risks. The following is a detailed explanation of these two categories of risks.

4.1 Risk of Common Attacks in WebSocket API

(1) Input Vulnerability in Message Body

Like the HTTP protocol, WebSocket API generally uses JSON format to transmit text when transmitting messages, so parameter injection, XSS, command execution, file reading, SSFR, arbitrary file upload, and other conventional input vulnerability attacks can still be carried out in the message body.

Vulnerability Case:

WebSocket API is used to transmit messages between the client and server in online chat applications. When a user enters a chat message, the following WebSocket message is sent to the server:

The server will forward this message content to another user through the WebSocket API, and then it will be rendered as a piece of HTML code in the browser of the other user.

When the server does not implement security defense or filtering for the forwarded content, XSS attacks can be carried out by modifying the WebSocket API message body.

(2) Bypassing Authentication

The WebSocket API does not specify how the server should authenticate the client identity during the handshake phase. The server can use any client identity authentication mechanism of an HTTP server, such as cookie authentication, HTTP basic authentication, TLS authentication, etc. The risks faced by WebSocket API in identity authentication are the same as those faced by traditional APIs, therefore, WebSocket API also faces the OWASP API 2023 Top Ten Security Risks API2: Risk of Authentication Failure.

(3) Authorization Failure

Like identity authentication, the WebSocket API does not explicitly specify any authorization method. The authorization strategy for user resource access and other aspects within the API is implemented by the server or the developer. The WebSocket API also faces the same security risks as traditional web applications, such as vertical privilege, horizontal privilege, unauthorized access, and other security risks. Therefore, the WebSocket API also faces the security risks of OWASP API 2023's top ten security risks, including API1: Object-level authorization failure, API3: Object attribute-level authorization failure, and API5: Function-level authorization failure.

(4) Denial of Service

The WebSocket API is also susceptible to denial of service attacks, with the risks divided into client-side denial of service risks and server-side denial of service risks.

• Client-side denial of service: The WebSocket connection limit is different from that of HTTP connections. WebSocket has a higher connection limit, and the maximum number of connections in different browsers also varies. By sending malicious content, all WebSocket connections can be occupied, leading to browser resource exhaustion and causing a denial of service.

• Server-side denial of service: The WebSocket connection is persistent. The connection will only close if either the client or the server initiates a request to close the connection. Attackers can launch requests and establish a large number of connections, leading to server resource exhaustion and triggering a denial of service attack.

4.2 Unique Attack Surface of WebSocket API

(1) Cross-site WebSocket Hijacking

When initiating a WebSocket handshake request through the WebSocket API, the browser adds an HTTP header named 'Origin' in the request. The 'Origin' field indicates the source from which the request is made, thereby preventing unauthorized cross-site access requests. The WebSocket specification does not stipulate that the 'Origin' header during the handshake phase is mandatory, and WebSocket is not subject to the browser's same-origin policy. If the server does not verify the 'Origin' header, it may lead to cross-site WebSocket hijacking attacks. When the WebSocket handshake request relies solely on HTTP cookies for session handling and does not include any CSRF token or other unpredictable values, this vulnerability may also occur. The attack risk is similar to JSONP hijacking and is a type of CSRF attack.

Vulnerability Example:

Send chat messages through real-time chat:

In the WebSocket handshake request, it is found that session handling is solely based on cookies, without CSRF protection measures.

View the WebSocket historical message records.

Find the exploit server in the browser.

At the same time, we set up a burp client in burp, which simulates the attacker.

Paste the exploit JS code into the exploit server.

Exploit the server and pass the exploit program to the victim, and then return the victim's related sensitive information in the burp client created by the attacker.

Decoding reveals the user's login credentials.

(2) Man-in-the-Middle Attack

This is also an attack risk that appears when manipulating the WebSocket handshake process, which can be implemented through the following attacks by obtaining and tampering with the WebSocket handshake request:

By forging client information to establish a WebSocket connection with the server; unconditional trust in HTTP headers, leading to some security policies being bypassed. For example: X-Forwarded-For header, XSS bypassing WAF; attack surface introduced by application-defined HTTP headers.

Vulnerability Case:

After XSS attacks were used in online chat, the attack was blocked and the WebSocket connection was terminated.

Intercept the WebSocket handshake request and bypass the blacklist using the X-Forwarded-For header.

After adopting this method to bypass, when the chat box reappears, it indicates that the blacklist detection has been bypassed and XSS attacks can be carried out. The subsequent steps can refer to the cases in the above message body input vulnerability attack.

4.3 Summary of Security Risks

In fact, almost all Web vulnerabilities may appear in WebSocket. Because, in essence, WebSocket is just a bidirectional full-duplex communication protocol established through HTTP, but due to its additional 'feature' compared to HTTP, some attack scenarios unique to WebSocket APIs may occur. Therefore, in addition to the security risks faced by traditional APIs, WebSocket APIs are also prone to attacks due to their own particularity, which come from the handshake request process of WebSocket APIs.