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.
The server can only push a resource to a client when the client requests it.
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.
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.
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.
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.
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?
- 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
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.
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.