WebSocket Security (WebSocket safety)

WebSocket Security

The WebSocket protocol is a young technology, and brings with it some risks. Decades of experience has taught the web community some best practices around HTTP security, but the security best practi Ces in the WebSocket world aren ' t firmly established, and continue to evolve. Nevertheless, some themes has emerged and they is described in this article.

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.

Heroku ' s SSL endpoints support WSS, and we strongly recommend it.

Avoid tunneling

It ' s relatively easy to tunnel arbitrary TCP services through a WebSocket. So-could, for-example, 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, Thu s allowing an escalation of a XSS attack to a complete remote breach.

We recommend avoiding tunneling if at all possible. Instead, develop more secured and checked protocols on top of WebSockets.

Validate Client Input

WebSocket Connections is easily established outside of a browser, so your should assume that you need to deal with Arbitra RY data. Just as with any data coming from a client, you should carefully validate input before processing it. SQL injection attacks is just as possible over WebSockets as they is over HTTP.

Validate Server Data

You should apply equal suspicion to data returned from the server, as well. Always process messages received on the client side as data. Don ' t try to assign them directly to the DOM, nor evaluate as code. If The response is JSON, always use to JSON.parse() safely parse the data.

Authentication/authorization

The WebSocket protocol doesn ' t handle authorization or authentication. Practically, this means the 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.

This can is done in a variety of ways, as WebSockets would pass through standard HTTP headers commonly used for Authenticat Ion. This means your could use the same authentication mechanism your ' re using for your Web views on WebSocket connections as wel L.

Since 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 has the server that handles WebSockets is completely separate from the one handling "normal" HTTP Requests. This can make shared authorization headers difficult or impossible.

So, one pattern we ' ve seen this seems to solve the WebSocket authentication problem OK is a "ticket"-based Authentica tion System. Broadly speaking, it works like this:

• When the Client-side code decides to open a WebSocket, it contacts the HTTP server to obtain an authorization "ticket".

• The server generates this ticket. It typically contains some sort of user/account ID, the IP of the client requesting the ticket, a timestamp, and any other Sort of internal record keeping you might need.

• The server stores this ticket (i.e. a database or cache), and also returns it to the client.

• The client opens the WebSocket connection, and sends along this "ticket" as part of a initial handshake.

• The server can then compare this ticket, check for source IPs, verify that the ticket hasn ' t been re-used and hasn ' t expired, And do any other sort of permission checking. If all goes well, the WebSocket connection are now verified.

[Thanks to Armin Ronacher-bringing this pattern to our attention.]

Origin Header

The WebSocket standard defines Origin -a header field, which Web browsers set to the URL that originates a WebSocket reques T. This can is used to differentiate between WebSocket connections from different hosts, or between those made from a brow Ser and some other kind of the network client. However, remember that the Origin header was essentially Advisory:non-browser clients can easily set the Origin header to an Y value, and thus "pretend" to be a browser.

You can think of the Origin headers as roughly analogous to the X-Requested-With header used by AJAX requests. Web browsers send a header X-Requested-With: XMLHttpRequest of, which can is used to distinguish between AJAX requests made by a browser and those Ma De directly. However, this header was easily set by Non-browser clients, and thus isn ' t trusted as a source of authentication.

In the same-on-the-advisory, you can use the header as a Origin mechanism-one that helps differentiate WebSocket requests fro M different locations and hosts, but you shouldn ' t rely on it as a source of authentication.

WebSocket Security (WebSocket safety)