Subscribe to our Blog

Get the Latest Application Security News and Content

WebSocket Security: Top 7 WebSocket Vulnerabilities

The basics

Why are WebSockets popular today? Because they greatly simplify the communication between a client and a server. Sockets, in general, have been used for network communication for a long time. However, restrictions exist for communications via browsers. Some of these restrictions include:

Client demands/Server responds

In the past servers had permanent listeners. The client (the one using the browser) didn’t have a fixed listener for long term connections. This made each communication centered around the client demanding and the server responding.

Client dependency

The server can only push a resource to a client when the client requests it.

Continual checking

Clients are constantly forced to refresh results from the server. Due to this reason libraries focus on making all asynchronous calls optimized. And they also have to identify their response. What’s the most common solution to this problem? Making on the fly functions referred to as callback functions.

While new technologies come with many benefits, they also introduce new problems. These days you can sandbox your browser on a new scale. This allows for riskier modes of access. Because of this, the implementation of WebSockets has become popular. WebSockets differ from your regular standard socket implementation. For example, the protocol still depends on http[s]. This protocol is defined by ws[s]:// and it always keeps the established connection open. Meaning it can send or receive messages continuously. In summary, WebSockets are important, and the fact that most web developers implement it into their websites often confirms that.

Most common WebSocket vulnerabilities

Let’s go over the most common WebSocket vulnerabilities and see how they’re exploited.

Most common WebSocket vulnerabilities include

  • DoS Attacks
  • No authentication during the handshake process
  • Unencrypted TCP channels
  • Vulnerability to input data attacks
  • Data masking
  • Authorization/authentication
  • Tunneling

DoS attacks

WebSockets let an unlimited number of connections reach the server. This lets an attacker flood the server with a DOS attack. This greatly strains the server and exhausts the resources on that server. Then the website slows down greatly.

No authentication during the handshake process

The problem here is that the WebSocket protocol doesn’t let a server authenticate the client during the handshake process. Only the normal mechanisms for HTTP connections are available. That includes HTTP and TLS authentication and cookies. The upgraded handshake still occurs from HTTP to WebSocket. But, the HTTP sends the authentication information directly to WS. This can be exploited and we call this attack Cross-Site WebSocket Hijacking.

Unencrypted TCP channels

Another issue with WebSockets is that they can be used over an unencrypted TCP channel. This leads to all kinds of issues that are listed in the OWASP Top 10 A6-Sensitive Data Exposure.

Vulnerability to input data attacks

What happens when a component is vulnerable to malicious input data attacks? A technique like Cross-Site Scripting. It’s a common yet very dangerous attack that can greatly damage your website. You can read more about Cross-Site Scripting in our blog that covered this vulnerability in-depthly.

Data masking

Data masking isn’t inherently bad. WebSockets protocols use it to stop things like proxy cache poisoning. However, there’s a problem. Masking prevents security tools from actions like identifying a pattern in the traffic. Software like DLP (Data Loss Prevention) isn’t even aware of the existence of WebSockets. This makes them unable to perform data analysis on WebSocket traffic. This also prevents these software programs from being able to identify things like malicious JavaScript and data leakage.

Authorization/authentication

A big flaw of WebSocket protocols is that they don’t handle authorization/authentication. Any application-level protocols need to handle this separately. Especially in cases when sensitive data gets transferred.

Tunneling

WebSockets let anyone tunnel an arbitrary TCP service. An example is tunneling a database connection directly through and reaching the browser. In the case of a Cross-Site Scripting attack it evolves and ends up becoming a complete security breach.

How to improve WebSocket security

The vulnerabilities have been covered. We now present some prevention guidelines to help protect your WebSockets.

Ticket-based authentication

As mentioned before, WebSocket protocols don’t handle authorization or authentication. How does one increase WebSocket security then? By optimizing and securing your connection. WebSockets pass through all standard HTTP headers that are used for authentication. Then why don’t we use the authentication mechanisms we use for our web views for WebSocket connections?

We can’t customize WebSocket headers from JavaScript. Unfortunately, everyone is limited to the “implicit” auth (cookies) that the browser sends. That’s not all, as the servers that handle WebSockets are usually separate from the ones that handle standard HTTP requests. This greatly hinders shared authorization headers. Thankfully there’s a pattern that helps with the WebSocket authentication problem. A ticket-based authentication system that works like this:

  • In the case where the client-side code tries to open a WebSocket, the HTTP server gets contacted to allow the client-side code to obtain an (authorization) ticket
  • Now the ticket gets generated, and it contains a user/account ID, the IP of the one requesting the ticket, a timestamp, and other internal record keeping
  • The ticket gets stored on the server/database and gets returned to the client
  • A client can now open the WebSocket connection and send this ticket together with the initial handshake
  • Now the server has the option of comparing the ticket, evaluating the source IP, verify the safety of the ticket (if it is re-used) etc.
  • When everything checks out, the WebSocket connection gets verified

Preventing tunneling

Tunneling arbitrary TCP services via a WebSocket is easy, as we’ve mentioned already. This is a risk that needs to be prevented. The best way to avoid this issue? Just avoid tunneling whenever possible. Using other secured and verified protocols on top of WebSockets is highly recommended. 

Client input validation

Arbitrary data. WebSocket connections can easily be established outside a browser. You will deal with arbitrary data no matter what. This data needs validation as well as any other that comes from a client before it gets processed. Why? Because injection attacks like OS, SQL, Blind SQL are possible via WebSockets. 

Server data validation

You don’t have to worry about only client data validation. Data that the server returns can also carry problems. Messages received on the client-side should always be processed as data. Assigning these messages directly to DOM or evaluating as code isn’t recommended. In the case of JSON responses, use JSON.parse() in combination with exception handling and if needed custom sanitization methods to parse the data safely.

WSS

You shouldn’t use ws://, it’s not a secure transport. Instead, use wss://, which is a much safer protocol. WSS is secure, so it prevents things like man-in-the-middle attacks. A secure transport prevents many attacks from the start.

In conclusion, WebSockets aren’t your standard socket implementation. WebSockets are versatile, the established connection is always open, and messages can be sent and received continuously. However, DOS attacks, no authentication/authorization, vulnerability to data input attacks are all vulnerabilities that are exploitable. That’s why it’s important to use client input and server data validation, ticket-based authentication, and WSS.

Check out more Cyber Security blogs at neuralegion.com/blog.

Get the Latest Application Security News and Content

SUBSCRIBE

Scale up efforts and set the new standard of integrating security into modern development!