OWASP Top 10 Details About WebSocket Vulnerabilities and Mitigations

Socket in a Nutshell

A socket is an endpoint of a network communication. A socket always comes in 2 parts: An IP address and a port.

For example: When you visit www.securelayer7.net, your computer and the website’s computer are communicating using sockets (endpoints). The endpoint of the website will be: www.securelayer7.net:80 and endpoint of your computer will be your IP address followed by any random port number like 192.168.0.111:6574

About WebSocket

Traditionally, the HTTP functions by client requesting resource and the server serving it. A server cannot on its own talk to the client. This limitation has been eliminated the new technology of WebSockets.

WebSockets provide a persistent connection also called as a full duplex connection between a client and server that both parties can use to start sending data at any time.

How does it work?

The client i.e. browser loads a web page that has WebSocket functionality.

The source of page has JavaScript responsible for creating WebSocket connection.

The script establishes a WebSocket connection through a process known as the WebSocket handshake. This process starts with the client sending a regular HTTP request to the server. An Upgrade header is included in this request that informs the server that the client wishes to establish a WebSocket connection.

The request looks like the following:

It is noteworthy to note that web sockets use ws as the scheme and not http. So, the above request went to the endpoint: ws://127.0.0.1:9000/websocket

If the server supports web sockets (for the above request), then it will reply with an Upgrade header in its response.

The response looks like the following:

At this stage, the protocol will be switched from HTTP to WS. And a full duplex connection will be established between browser and server.

In this illustration, we have a WebSocket functionality that echo’s back all the words sent by the client. For example: If the user types the word ‘Hiii’ then the server will also reply with ‘Hiii’.

The request:

The response:

The user interface:

Now let us understand the security implications of WebSockets:

A. Cross-site WebSocket Hijacking

Observe the below request. The Origin header has a different origin 127.0.0.1:5555. The request is sent using the victim’s cookies to the WebSocket server. This means that an attack similar to CSRF can be delivered using WebSockets.

But this attack will not only POST data to the WebSocket server like CSRF, but also read the server responses back. This is because WebSocket server by default does not check ‘Origin’ header, it simply checks authenticated users session using cookies and sends back the response to the requesting Origin.

Thus, in the above scenario, the attacker can also read the response, hence controlling two way communications on behalf of the victim.

Mitigation:

• Checking the ‘Origin’ header of the request. Since, this header was designed to protect against cross origin attacks. If the ‘Origin’ is not trusted, then simply reject the request. For example: If your site has domain as www.example.com , then check if the request originates from that origin, if yes, then process it. If no, then reject it.
• Another solution is to use session based individual random tokens (just like CSRF-Tokens). Generate them server side and have them in hidden fields on client side. And verify them at request.

B. Sensitive information disclosure over network

Just like HTTP is a plain text protocol, the WebSockets protocol aka WS is also plain text. This leads to attacker capturing and modifying the traffic over the network.

Mitigation:

• Use of encrypted (TLS) WebSockets connection is recommended. The URI scheme for it is wss:// . And the default port is 443.
• In our demo, the request went to ws://127.0.0.1:900/websocket/. Had it been a secure connection, then the request would have went to wss://127.0.0.1:900/websocket/

C. Denial of Service

WebSockets allow unlimited connections by default which leads to DOS. Following is a tiny script that connects to the WebSocket server infinite times.

After executing this script, let us see the logs of WebSocket server:

As we can see, within few seconds almost 475 connections were made. This will exhaust the server resources ultimately leading to DOS attack.

Mitigation:

• Use of rate limiting based on IP will help solve this issue.
• The rate limiting should allow 5-10 connection freely i.e. without any security checks. But after 10 connections, if the same IP tries to connect then the user should be presented with CAPTCHA in order to ensure that an automated tool is not making the malicious requests and at the same time the legitimate users are not denied of the service.

Conclusion:

WebSockets is great for full duplex communication. It is used by many of chatting applications and social networking sites. Implementing WebSockets make the application more usable and attractive.

But just like any other technology, this too, needs to be implemented with taking security into considerations.

References:

• The code for demonstration was taken from: https://github.com/ghedipunk/PHP-Websockets
• About WebSockets: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications
• Security implications: https://www.owasp.org/index.php/Testing_WebSockets_(OTG-CLIENT-010)