What is a WebSocket?

WebSocket is a Client-Server Bidirectional Communication protocol initiated over HTTP.

WebSockets are used where there is continuous streaming of data over a network or where some real-time details are required by the application. Examples of such cases will be real-time web applications, gaming applications, chat applications, etc.

 

Difference between WebSocket and HTTP

Although both the HTTP and WebSockets are used as communication protocol, there are some differences between the two. They are noted below

Difference between WebSocket and HTTP

 

The WebSocket Handshake Request and Response 

For a WebSocket connection, the client sends the handshake request to the server, and then the server will return the handshake response. Fig 1.1 shows the WebSocket Handshake connection establishment request and response captured in Burp Suite.

WebSocket Handshake Request and Response

Fig 1.3: WebSocket Handshake Request and Response

 

WebSocket Handshake Request Headers:

  1. Upgrade:

This header is used by the client to ask the server to switch to the “WebSocket” protocol.

  1. Connection:

This header is used to define if the network connection will be open or not after the current transaction.

  1. Sec-WebSocket-Version:

This header specifies the WebSocket version used for communication. The latest version is 13.

  1. Sec-WebSocket-Key:

This header contains a base64 encoded random value.

  1. Sec-WebSocket-Protocol:

This header specifies the protocol in use.

 

WebSocket Handshake Response Headers:

  1. Sec-WebSocket-Accept:

This header value is obtained by appending the Sec-WebSocket-Key value specified in the request with fixed string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11, taking the SHA-1 hash of it and then encoding the result using base64.

 

WebSocket Vulnerabilities

  1. Encrypted and unencrypted WebSocket:

There are two WebSocket connection modes or the two new URI schemes for WebSockets i.e. ws (WebSocket) and wss (WebSocket Secure).

  • Unencrypted connection is specified as ws:// (port is 80)
  • Encrypted connection is specified as wss:// (port is 443)

Only the encrypted mode uses TLS/SSL encryption to encrypt all data sent to and from the server which also includes the initial handshake request and response. The use of an unencrypted connection may lead to the transfer of the data into plain text and hence help an attacker to capture and modify all the traffic over a network.

  1. Tampering the WebSocket message content:

Let us consider an example of a chat-bot using the WebSockets.

Consider that the application will encode all the special characters before sending them to the server. This will prevent the attacker from sending the XSS payload through the chat message box. Fig 1.4 shows the payload and its encoded form in Burp Suite.

Tampering the WebSocket Message-1

Fig. 1.4: Tampering the WebSocket Message-1

However, you can try to manipulate the request, add the XSS payload through Burp, and perform the XSS attack as shown in fig. 1.5.

Tampering the WebSocket Message-2

Fig. 1.5. Tampering the WebSocket Message-2

 

  1. Manipulating WebSocket Handshake:

Another WebSocket vulnerability can be found in the WebSocket Handshake Connection by manipulating the Web Socket Handshake. Consider an example where you enter the malicious payload to attack the target server and your IP address gets blocked for any further communication/handshake requests with that server. In this case, we can use the X-Forwaded-For header to re-establish the WebSocket Connection.

  1. Cross-Site WebSocket Hijacking:

WebSocket handshake is completely dependent on the HTTP cookies for the session management and does not contain any CSRF token or random unpredictable value of its own. Also, WebSocket is not restrained by the same-origin policy (The SOP is a way of preventing unwanted data access from malicious domains).

Cross-Site WebSocket Hijacking (CSWSH) involves a CSRF vulnerability on the WebSocket handshake and is also known as cross-origin WebSocket hijacking.

In CSWSH an attacker creates a malicious web page on his domain to initiate a web socket connection with the vulnerable application. The attacker will then trick the victim into accessing this page and control the messages sent and received over the WebSocket connection. The malicious web page script will allow an attacker to access all the cookie values of the victim and in many cases, the credentials sent to the victim from the server through the WebSocket handshake request.

A successful CSWSH attack will lead an attacker

  • To retrieve sensitive data about the target application and its users.
  • To perform unauthorized actions on behalf of the victim.

 

Security Best Practices

  1. WebSocket Connection should be initiated over wss.
  2. Check the Origin Header for the WebSocket Handshake to validate from where the handshake request is coming and protect the server from cross-site connections initiated through victim browsers.
  3. Make use of random tokens or CSRF tokens and implement the server-side validations of these tokens.
  4. Provide input validations at both the client and server ends to prevent vulnerabilities such as SQL Injection and Cross-Scripting attacks. The data received from both ends should be treated as untrusted.

To know more do visit our website.

 

References:

https://en.wikipedia.org/wiki/WebSocket#Protocol_handshake

https://www.tutorialspoint.com/websockets/websockets_functionalities.htm

https://developer.mozilla.org/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism

https://www.praetorian.com/blog/cross-site-websocket-hijacking-cswsh/?edition=2019

 

 

Author,

Vaibhavi Gandhi

Attack & Pentest Team

Varutra Consulting Pvt. Ltd.