IMCAFS

 Home

tencent security emergency response center

Posted by santillano at 2020-04-07
all

1. Introduction to websocket features

WebSocket is a kind of full duplex communication network technology between browser and server, which is provided by HTML5. Websocket communication protocol was set as standard RFC 6455 by IETF in 2011, and websocket API was also set as standard by W3C. Mainstream browsers have supported websocket communication.

Websocket protocol is an independent communication protocol based on TCP protocol. Before establishing a websocket communication connection, it needs to use HTTP protocol to handshake and upgrade from HTTP connection to websocket connection. The browser and the server only need to complete one handshake, and they can directly create a persistent connection and carry out two-way data transmission.

Websocket defines two URI formats, "WS: / /" and "WSS: / /", similar to HTTP and HTTPS, "WS: / /" uses clear text transmission, and the default port is 80, "WSS: / /" uses TLS encryption transmission, and the default port is 443.

ws-URI : "ws://host[:port]path[?query]" wss-URI : "wss://host[:port]path[?query]"

During the handshake phase of websocket, some HTTP headers are required. Upgrade the HTTP connection to websocket connection as shown in the following table.

A complete handshake connection is as follows:

Once the server returns a 101 response, the websocket protocol switch can be completed. The server can switch the communication protocol from http: / / or HTTPS: / / to WS: / / or WSS: / /, based on the same port. After the protocol switch, the browser and the server can send and receive text and binary messages to each other using the websocket API.

2. Websocket application security

Websocket introduced into web application as a communication protocol will not solve the security problems in web application, so the security implementation of websocket application is the responsibility of the developer or server. This requires developers to understand the potential security risks of websocket applications and how to avoid these security problems.

2.1 certification

The websocket protocol does not specify how the server should authenticate the client during the handshake phase. The server can use any client authentication mechanism of HTTP server, such as Cookie authentication, HTTP basic authentication, TLS authentication, etc. The security problems faced in the implementation of websocket application authentication are the same as traditional web application authentication, such as cve-2015-0201. The Java sockjs client of spring framework generates predictable session ID, which can be used by attackers to send messages to other sessions; cve-2015-1482, Ansible tower does not authenticate the user's identity, and remote attackers obtain sensitive information through websocket connection.

2.2 authorization

As with authentication, websocket protocol does not specify any authorization method, and the authorization policy of user resource access in application program is implemented by server or developer. Websocket applications also have the same security risks as traditional web applications, such as vertical and horizontal permissions.

2.3 cross domain request

Websocket uses a source based security model. When a websocket handshake request is initiated, the browser will add an HTTP header named origin to the request. The oringin field represents the source of the request, so as to prevent unauthorized cross site access to the request. The client of websocket is not limited to browser, so the specification of websocket does not stipulate that the origin header of handshake phase is necessary, and websocket is not limited by the browser homology policy. If the server does not verify the origin header, it may lead to cross site websocket hijacking attack. The vulnerability was first discovered and disclosed by Christian Schneider in 2013, and Christian named it cross site websocket hijacking (cswsh). Cross site websocket hijacking is harmful, but it is easy to be ignored by developers. For relevant cases, please refer to: IPython notebook (cve-2014-3429), openstack compute (cve-2015-0259), Zeppelin websocket server and other cross site websocket hijacking.

The figure above shows the process of cross site websocket hijacking. A user has logged in to the websocket application. If he is deceived to visit a malicious web page, and a section of JS code is embedded in the malicious web page, he will automatically initiate a websocket handshake request to establish a websocket connection with the target application. Note that origin and SEC websocket key are generated automatically by the browser. The browser will automatically bring the cookie and other authentication parameters to the target server when it sends a request to access the server again. If the server does not check the origin header, the request will successfully handshake and switch to the websocket protocol. Malicious web pages can successfully bypass the identity authentication to connect to the websocket server, and then steal the information sent from the server, or send forged information to the server to tamper with the server data. Compared with traditional Cross Site Request Forgery (CSRF) attacks, CSRF mainly sends data modification requests through malicious web pages, while cross site websocket forgery attacks can not only modify server data, but also control the entire two-way communication channel. For this reason, Christian named the vulnerability hijacking rather than request forgery.

Understand the principle and process of cross site websocket hijacking attack, so how to prevent this attack? The processing is also relatively simple. The check of origin header is added to the code on the server side. If the origin information sent by the client comes from different domains, the server side can reject the request. However, only checking origin is still not safe. Malicious web pages can forge origin header information and bypass the server's checking of origin header. A more perfect solution can learn from CSRF's solution token mechanism.

2.4 denial of service

Websocket is designed as a connection oriented protocol, which can be exploited to cause denial of service attacks on clients and servers. For related cases, please refer to F5 BIG-IP Remote Denial of Service Vulnerability (cve-2016-9253).

(1) . client denial of service

Websocket connection limit is different from HTTP connection limit. Compared with HTTP, websocket has a higher connection limit. Different browsers have their own specific maximum number of connections. For example, the default maximum number of connections for Firefox is 200. By sending malicious content, all allowed websocket connections are exhausted and browser resources are exhausted, resulting in a denial of service.

(2) . server side denial of service

Websocket establishes a persistent connection. Only when one of the clients or servers requests to close the connection, the websocket connection will be closed. Therefore, an attacker can send a large number of requests to the server to establish a websocket connection, establish a persistent connection, exhaust server resources, and cause a denial of service. For this kind of attack, it can be prevented by setting the maximum number of connections that a single IP can establish. The attacker can also send a single huge data frame (such as 2 ^ 16) or a small frame of a long stream fragment message to exhaust the memory of the server and cause a denial of service attack. For this attack, the attacker can prevent it by limiting the frame size and the total message size after multiple frames are reorganized.

2.5 man in the middle attack

Websocket uses HTTP or HTTPS protocol for handshake request. In the case of HTTP protocol, if there is an intermediary who can sniff HTTP traffic, the intermediary can obtain and tamper with websocket handshake request, and establish websocket connection with the server by forging client information, as shown in the following figure. To prevent this kind of attack, we need to establish websocket connection on the encrypted channel and use HTTPS protocol to initiate handshake request.

2.6 input verification

Like traditional web applications, websocket applications need to verify the input to prevent XSS attacks from the client, SQL injection from the server, code injection and other attacks.

3. summary

Websocket is a new protocol of HTML5 based on TCP, which can realize full duplex communication between browser and server. In instant messaging applications, websocket has great performance advantages and is very suitable for full duplex communication. However, as with any other technology, the development of websocket applications also needs to consider potential security risks.

4. reference

© 2023