In this article, we will be examining WebSockets and how they differ from an HTTP request. We will also discuss exploitation of a cross-site request forgery on a WebSocket-based web application, and related security measures organizations should take to protect their applications.

Introduction

In recent years, WebSockets have become an increasingly popular technology for building real-time, interactive applications such as online games, chats, and live data updates. A WebSocket is a protocol that allows bi-directional communication between a client and a server over a single, long-lived connection, providing a fast and efficient way to transfer data between the two parties.

To effectively use WebSockets, follow these steps:

1. Choose a WebSocket library that fits your development stack. The following libraries can be considered:

• Socket.IO: Socket.IO is a JavaScript-based library that allows real-time bidirectional communication between the server and the client.

• Django Channels: Django Channels is a Python-based library that integrates seamlessly with Django-based applications and provides a high-level API that allows real-time bidirectional communication between the server and client.

• Ratchet: Ratchet is a PHP-based library that allows you to build real-time applications with bidirectional communication between the server and clients.

2. Establish a WebSocket connection between the client and the server:

• Set up a communication channel between the client and server that allows bidirectional communication. WebSockets provide a persistent connection that enables continuous communication.

• The client and server must go through a handshake process to establish a WebSocket connection. The client sends a special HTTP request to the server that indicates that it needs to upgrade the connection to WebSocket. The server acknowledges the same by sending a similar HTTP response completing the handshake process.

• Once the handshake process is completed, the connection transitions from HTTP to the WebSocket protocol establishing the bidirectional connection, and the client and server can send asynchronous messages.

• Once the required messages are sent back and forth between the client and the server, either party can send a close frame which indicates that the connection can be closed gracefully. The connection is considered closed once both parties have sent and received the close frames.  

3. Implement the server-side logic to handle incoming data, and broadcast it to connected clients, if necessary.

4. Implement the client-side logic to receive and process messages from the server.

5. Ensure that the WebSocket connection is adequately secured using SSL/TLS.

Lastly, consider the following best practices:

• Keep the messages small and concise for better performance.

• Handle disconnections and reconnections gracefully.

• Implement error handling and logging to diagnose and fix issues.

• Test your WebSockets implementation under different network conditions and with various payload sizes.

WebSockets and HTTP Requests: Understanding the Difference

Web development revolutionized how real-time communication is achieved on the web but how do WebSockets differ from Hypertext Transfer Protocol (HTTP) requests?

HTTP is the foundation of data communication on the World Wide Web. It is a request-response protocol in which a client sends a request to a server, and the server returns a response. HTTP is typically used for one-time requests, such as fetching a web page or uploading a file.

WebSockets provide a full-duplex communication channel between the client and the server. Unlike HTTP, which is limited to one request-response cycle, WebSockets allow for real-time, bi-directional communication between the client and server. This means both parties can send data anytime without waiting for a request or response.

One of the key differences between WebSockets and HTTP is how they initiate and maintain a connection. HTTP uses a separate connection for each request, which must be closed after receiving the response. On the other hand, WebSockets maintain a persistent connection between the client and server, allowing for real-time communication.

Web Sockets and HTTP are essential technologies in modern web development. However, they serve different purposes and have distinct differences initiating and maintaining connections, and transmitting data. WebSockets provide a powerful solution for real-time, bi-directional communication on the web, while HTTP remains a cornerstone for one-time requests and data retrieval.

What is Cross-site WebSockets Hijacking (CSWSH)?

Cross-site WebSockets Hijacking (CSWSH) is a security vulnerability that allows an attacker to intercept and manipulate a WebSockets connection between a client and a server. The attacker tricks the client into sending WebSocket requests to a malicious server instead of the intended server. This ingress can lead to sensitive data theft, server compromise, or malicious actions.

How does CSWSH work?

CSWSH exploits a weakness in how WebSockets connections are established and maintained. When a client and a server establish a WebSockets connection, they exchange messages to negotiate the connection parameters, such as the connection type, compression options, and security protocols. Once the connection has been established, the client and server can send and receive data to each other over the same connection until either party decides to close the connection.

The vulnerability in WebSockets lies in how the client and server authenticate each other. Unlike traditional HTTP requests, WebSockets do not include security mechanisms, such as cookies or HTTP headers, to authenticate the client and the server. Therefore, once a client has established a WebSocket connection with a server, the server does not know whether the client is who it claims to be.

An attacker can exploit this vulnerability by intercepting the WebSocket connection between the client and the server and sending malicious data to either the client or the server. The attacker uses techniques such as man-in-the-middle (MitM) or cross-site scripting (XSS) attacks. For example, an attacker could use an XSS vulnerability in a website to inject malicious JavaScript code into the client's browser, which can then send WebSocket requests to a malicious server instead of the intended server. The attacker could then use the intercepted WebSockets connection to steal sensitive information, such as login credentials or financial data.

To determine if an application is vulnerable to CSWSH, follow these steps:

1. Check for SSL/TLS encryption: Start by checking if the WebSocket connection uses SSL/TLS encryption to secure the communication between the client and the server. You can use tools such as Wireshark or the browser developer tools to inspect the network traffic and verify that the WebSockets connection is encrypted.

2. Verify origin-based access control: Next, verify that the server-side WebSockets connection implements origin-based access control. This validation will ensure that WebSocket connections are only accepted from trusted origins and that connections from untrusted sources are rejected.

3. Inspect the WebSocket handshake: Inspect the WebSocket handshake process to see if the client and server are properly authenticated and authorized. This verification will help determine if the WebSocket connection is vulnerable to hijacking.

4. Conduct a man-in-the-middle attack: Conduct a man-in-the-middle (MitM) attack to see if it is possible to intercept and manipulate the WebSockets connection. You can use tools such as Burp Suite or ZAP to conduct the attack.

5. Check for malicious data injection: Finally, check for malicious data injection by sending data over the WebSockets connection, and verify that the data is properly validated and sanitized on the server side.

It is important to remember that these are just a few steps involved to determine if an application is vulnerable to CSWSH and that a thorough security assessment may involve additional techniques and tools.

Protecting against CSWSH

To protect against CSWSH, consider the following practices:

1. Use SSL/TLS encryption to secure the WebSockets connections. This feature will ensure that all data sent over the WebSockets connection is encrypted, making it more difficult for an attacker to intercept and manipulate the connection.

2. Implement origin-based access control on the server side. This enforcement will ensure that WebSockets connections are only accepted from trusted origins and that connections from untrusted sources are rejected.

3. Validate and sanitize all data sent over WebSockets. This step will prevent an attacker from injecting malicious data into the WebSockets connection, which could compromise the server or steal sensitive information.

4. Use JSON Web Tokens (JWT) or similar mechanisms to authenticate and authorize the client and the server. This measure ensures that only trusted parties are allowed to communicate over WebSockets.

It is important to remember that the remediation of CSWSH is an ongoing process, and regularly reviewing and updating security measures is paramount to prevent new vulnerabilities from being introduced.

References:

1. WebSocket testing guide (OWASP)

2. Testing for WebSockets security vulnerabilities (Portswigger)

3. OWASP Damn Vulnerable Web Sockets

4. DVWS Github

5. DVWS docker image

6. Exploit code

About the Author

Omkar Avasthi is Security Engineer at Certus Cybersecurity and is specialist in vulnerability assessment and penetration testing on a variety of web and mobile applications withc insight from a Blue team perspective.