What is WebSocket and how to secure it?

WebSocket is a protocol for creating a fast two-way channel between a web browser and a server. WebSocket overcomes limitations with HTTP to allow for low latency communications between a user and a web service.

In 2013, Google released World Wide Maze (WWM), a game that turns web pages into a 3D maze. Built on WebSockets, WWM uses Chrome to turn a mobile device into a controller while displaying the output to a monitor or TV.

The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011, and the WebSocket API in Web IDL is being standardized by the W3C.

WebSocket brings truly instant communication to the web, making websites look and feel more like local applications.

With this technology, a user can send messages to a server and receive event-driven responses without having to constantly check the server for a reply.

How does WebSocket different from other technologies?

Several paradigms have been created to facilitate two-way communication between a browser and a server. One of the biggest differences between these approaches and WebSocket is that these approaches still rely on HTTP, whereas WebSocket is its own protocol.

For example, AJAX is a technique for updating the contents of a page without refreshing the entire page. Rather than interrupt the user’s session, it modifies part of the web page as it appears in the user’s browser. The browser can communicate any changes to and from the server without having to reload the entire page. The pitfall of AJAX is that it’s still a one-way communication. The server can’t push data to the user. Instead, the user has to poll the server for changes. Since AJAX works over HTTP, a new connection has to be created each time an AJAX request is made.

And on the other side, WebSockets overcomes both of these limitations by establishing a persistent connection that the server can push data over.

WebSockets can also facilitate two-way communication between a user and a service, recognizing events and displaying them to the user as they occur.

What is it used for?

The real-world applications for WebSockets are endless, including chatting apps, internet of things, online multiplayer games, and really just any real-time application.

Why should use a WebSocket?

A WebSocket is a continuous connection between client and server. That continuous connection allows:

Data can be sent from server to client at any time, without the client even requesting it. This is often called server-push and is very valuable for applications where the client needs to know fairly quickly when something happens on the server. A client cannot be pushed data over HTTP. The client would have to regularly poll by making an HTTP request every few seconds in order to get timely new data. Client polling is not efficient.

Data can be sent either way very efficiently. Because the connection is already established and a WebSocket data frame is very efficiently organized, one can send data a lot more efficiently than via an HTTP request that necessarily contains headers, cookies, etc...

WebSockets adds flavor to the web by allowing websites to update content without having to wait for the user. Unlike other techniques which piggyback on the HTTP protocol, the WebSocket protocol creates a true ongoing connection between the user and the web service, allowing information to flow easily between both endpoints.

With WebSockets, service providers can create a powerful, low latency channel between their content and their customers.

With WebSockets, the users enjoy a seamless, uninterrupted experience since their browser is constantly communicating with the server, delivering new content immediately rather than when it’s requested. Enterprises see higher customer satisfaction and engagement as customers enjoy a more dynamic and fluid experience.

How does it work?

A request to a WebSocket connection is sent to the server from a client (or multiple clients) through a process called the WebSocket handshake, which starts with the client sending a regular HTTP request to the server. Part of this request includes an Upgrade header, which indicates to the server that the client is trying to make a WebSocket connection. This request is called a WebSocket handshake.

If the server accepts the handshake and supports the protocol, the initial HTTP connection is replaced with a WebSocket connection using the same TCP / IP protocol.

And that connection is maintained for each client, allowing data to be pushed in real-time back to the client from the server on demand. Because this connection between the server and client remains open, it eliminates the need for constant checking to see if new information has been stored on the backend. By doing so, this eliminates the need for constant fetch requests to the backend server.

WebSockets don’t require a user to send a request in order for the server to respond. Instead, the server returns any information as it gets it, so the user side just has to listen for that information.

WebSockets have a much lower latency in terms of messages being sent to their clients, due to the open connection.

WebSockets just sends the response as soon as it gets it in real-time.

How to secure it?

The WebSocket protocol is a young technology and brings with it some risks. Websockets allow us to achieve real-time communication among different clients connected to a server. But people are unaware of how to secure their web sockets against some very common attacks. So, here are some common practices.

WSS

You should strongly prefer the secure wss:// protocol over the insecure ws:// transport. Like HTTPS, WSS (WebSockets over SSL/TLS) is encrypted, thus protecting against man-in-the-middle attacks. A variety of attacks against WebSockets become impossible if the transport is secured.

Enable CORS

WebSocket doesn’t come with CORS inbuilt. It means that any website can connect to any other website’s WebSocket connection and communicate without any restriction! A quick fix to this is to verify Origin header on the WebSocket handshake.

Avoid tunneling

It’s relatively easy to tunnel arbitrary TCP services through a WebSocket. So you could tunnel a database connection directly through to the browser. This is very dangerous, however. Doing so would enable access to these services to an in-browser attacker in the case of a cross-site scripting attack, thus allowing an escalation of an XSS attack into a complete remote breach. So, avoid tunneling if at all possible.

Authentication and authorization

The WebSocket protocol doesn’t handle authorization or authentication. Practically, this means that a WebSocket opened from a page behind auth doesn’t “automatically” receive any sort of auth; you need to take steps to also secure the WebSocket connection. Since you cannot customize WebSocket headers from JavaScript, you’re limited to the “implicit” auth (i.e. Basic or cookies) that’s sent from the browser. Further, it’s common to have the server that handles WebSockets be completely separate from the one handling “normal” HTTP requests. This can make shared authorization headers difficult or impossible.

Restrict payload size

This should be implemented as a feature within your server-side web socket library. If not, its time to change it to a better one! You should limit the maximum length of the message that could be sent over your WebSocket. Theoretically, there is no limit. Of course, getting a huge payload is very likely to hang that particular socket instance and eat up more system resources than required.

Validate client input

WebSocket connections are easily established outside of a browser, so you should assume that you need to deal with arbitrary data. Just as with any data coming from a client, you should carefully validate input before processing it.