WebSocket Security: Top 8 Vulnerabilities and How to Solve Them
What is a WebSocket?
WebSockets are becoming increasingly popular, because they greatly simplify the communication between a client and a server.
The WebSocket protocol uses OSI model application layer (Layer 7) to allow a client and server to perform bidirectional (full duplix) communication. This makes it possible to create dynamic, real-time web applications such as instant messaging and photo sharing apps.
This is part of a series of articles about Web Application Security.
WebSockets overcome some of the traditional restrictions of communications between browsers and servers:
- Client requests/server responds – n 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.
- Communication dependent on client – he 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. This is why libraries focus on making all asynchronous calls optimized. They also have to identify their response. The most common solution to this problem is the use of callback functions.
WebSocket overcomes the latency inherent in unidirectional communication from the client to the browser. In the http[s]:// protocol, the client initiates a request and waits for a response. This is called a transaction. Each request/response starts a different transaction, and each transaction has an overhead. In the ws[s]:// protocol, WebSockets initiate long-lived transactions with multiple requests and responses. The server can also send data without prior request, making communication much more efficient.
This is part of a series of articles about Web Application Security.
In this article:
Most Common WebSocket Vulnerabilities
Let’s go over the most common WebSocket vulnerabilities and see how they’re exploited.
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.
Learn more in our detailed blog post about Cross-Site Scripting.
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.
Learn more in our detailed guide to mobile security.
WhenSocket 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.
Sniffing Attacks
Data transfer over the WebSocket protocol is done in plain text, similar to HTTP. Therefore, this data is vulnerable to man-in-the-middle attacks. To prevent information leakage, use the WebSocket Secure (wss://) protocol. Like HTTPS, wss doesn’t mean your web application is secure, but ensures that data transmission is encrypted using Transport Layer Security (TLS).
How to Improve WebSocket Security
The vulnerabilities have been covered. We now present some prevention guidelines to help protect your WebSockets.
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.
Related content: Read our guide to security testing tools.
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.
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.Â
Learn more in our detailed guide to web application scanning.
Rate Limiting
Rate limiting is an important way to prevent abuse of your web application or web service. It can protect against bad bots, scraping attacks, and small-scale denial of service (DoS) attacks. In some cases, a malfunctioning client can result in an accidental DoS attack.
To implement rate limiting, assign a “bucket” to every user, and determine the following parameters:
- How much websocket traffic is sent by the user per second
- How much traffic the server can safely process per second
- Traffic from the same user that exceeds the server’s capacity should be placed in a queue
- The server should allow a certain timeout period, to allow for bursty traffic by the client followed by a quiet period, in which the server can process the queue
- After the timeout, messages in the queue should be discarded
Related content: Read our guide to security testing tools.
Origin Header
The WebSocket standard lets you define an Origin header field. This is similar to the AJAX X-Requested-With header. It determines which host a WebSocket connection is coming from. Otherwise the client can communicate with any host over the WebSocket protocol.
The Origin header is advisory, and can be faked by an attacker. But still, this would require an attacker to change the Origin header on the client browser, which is blocked by modern browsers in most circumstances. So, while it is a good idea to set the Origin field, you should not rely on it for authentication – always combine it with cookies or another authentication mechanism.
