In modern web development, real-time interactions and instant updates are increasingly vital making WebSockets as a cornerstone technology. These communication channels offer a bridge between clients and servers, facilitating bidirectional data flow with minimal latency.
However, with great power comes great responsibility, and understanding the intricacies of WebSocket protocols is essential for fortifying against potential security vulnerabilities. So, in this blog let’s explore WebSocket’s fundamental workings, distinguishing features compared to traditional HTTP, and the various security risks they entail.
What are WebSocket’s?
WebSocket’s is a communication protocol that provides full-duplex communication channels over a single, long-lived connection. It enables real-time, bidirectional communication between a client (such as a web browser) and a server. Unlike traditional HTTP requests, which are stateless and involve creating a new connection for each request, WebSockets allow continuous communication between the client and server.
WebSockets are supported by most modern web browsers, making them a popular choice for developing real-time web applications. In addition to browser-based applications, WebSockets are also used in server-to-server communication and are supported by various programming languages and frameworks. The WebSocket API in JavaScript provides a convenient way to work with WebSocket’s in web applications.
HTTP v/s WebSocket’s
In the realm of web communication, HTTP is the prevalent protocol where clients make requests and servers respond promptly, usually concluding the transaction swiftly. Even if the network connection remains open, it is typically reserved for separate, transactional exchanges involving distinct requests and responses.
In contrast, modern websites may leverage WebSockets, which are initiated through HTTP but are characterized by their enduring nature. Unlike HTTP, WebSocket connections persist, remaining open and idle until either the client or server decides to dispatch a message. These messages can flow bidirectionally at any moment, and the communication is not bound by the transactional structure of traditional HTTP interactions.
WebSocket’s prove invaluable in scenarios demanding low-latency or when messages need to be initiated by the server, as exemplified in real-time financial data feeds where immediate updates are crucial.
How are the WebSocket’s connections established?
- WebSocket connections are normally created using client-side JavaScript like the following:
The wss protocol establishes a WebSocket over an encrypted TLS connection, while the ws protocol uses an unencrypted connection.
During the initiation of a connection, the browser and server engage in a WebSocket handshake over HTTP. The browser initiates this process by sending a WebSocket handshake request, typically including specific headers such as “Upgrade,” “Connection,” and “Sec-WebSocket-Key.”
- If the server accepts the connection, it returns a WebSocket handshake response like the following:
Cross-site WebSocket hijacking
Cross-site WebSocket hijacking, also known as cross-origin WebSocket hijacking, exploits a WebSocket handshake’s CSRF vulnerability. This occurs when the WebSocket handshake relies solely on HTTP cookies for session management and lacks CSRF tokens or other unpredictable values.
In this scenario, an attacker crafts a malicious web page on their domain, establishing a cross-site WebSocket connection with the vulnerable application. This connection is handled within the context of the victim user’s session.
Once established, the attacker’s page gains the ability to send arbitrary messages to the server through the WebSocket connection and read the contents of messages received from the server. Unlike conventional CSRF, this attack enables the attacker to engage in two-way interaction with the compromised application.
Case-Study: Performing a Cross-site WebSocket hijacking attack in Real world.
Let us discuss about the Cross Site Websocket Hijacking attack in a simple pentesting scenario.
Here the application does not validate the Origin header, making it vulnerable to WebSocket hijacking.
The application appears that it trusts the WebSocket upgrading request with an arbitrary origin header.
Arbitrary Origin Trusted
A specially crafted JavaScript with required parameters sends the request to the target WebSocket. The server will respond with the intended data, and then the received data will be sent to the burp collaborator domain (Attacker’s server).
JavaScript Code
As we can see below, the responded data from the server is received in burp collaborator.
Data exfiltrated to the attacker’s server
The above data’s are exfiltrated by WebSocket Hijacking.
Other Common Security Risks in WebSocket.
WebSocket, like any other technology, can be susceptible to various security threats and attacks. Some other common WebSocket attacks include:
- Cross-Site Scripting (XSS) :
WebSocket applications may be vulnerable to XSS attacks if they don’t properly validate and sanitize user inputs. Malicious scripts injected into the application can potentially manipulate WebSocket messages and compromise security.
- Denial of Service (DoS) and Distributed Denial of Service (DDoS) :
WebSocket servers can be targeted with DoS or DDoS attacks to overwhelm the server with a high volume of connection requests or messages, causing service degradation or disruption.
- Message Tampering :
Attackers may attempt to tamper with WebSocket messages during transit. This can include modifying the content of messages or injecting malicious payloads to compromise the integrity and security of the communication.
- Protocol-Level Attacks :
WebSocket relies on a specific protocol, and attackers may attempt to exploit vulnerabilities in the protocol implementation. This could involve manipulating handshake messages or exploiting weaknesses in the WebSocket protocol itself.
- Session Management Issues :
Inadequate session management can lead to security issues. If WebSocket sessions are not properly authenticated, authorized, or managed, it may result in unauthorized access to sensitive data or actions.
- WebSockets Over Insecure Connections :
If WebSocket connections are established over unencrypted (HTTP) rather than encrypted (HTTPS) connections, it opens the door to man-in-the-middle attacks, where an attacker could intercept and manipulate the WebSocket traffic.
Securing a WebSocket connection
To minimize the risk of security vulnerabilities arising with WebSocket’s, use the following guidelines:
- Implementing proper input validation and output encoding to prevent XSS attacks.
- Using secure, encrypted connections (SSL/TLS) to protect WebSocket communication.
- Implementing strong authentication and authorization mechanisms.
- Protect the WebSocket handshake message against CSRF, to avoid cross-site WebSockets hijacking vulnerabilities.
- Monitoring and rate limiting WebSocket connections to detect and mitigate DoS/DDoS attacks.
- Regularly updating and patching WebSocket server software to address vulnerabilities.
Concluding thoughts
While WebSocket’s offer unparalleled real-time communication capabilities, they also introduce a host of security considerations. From the risk of Cross-Site Scripting (XSS) to potential Denial of Service (DoS) attacks, safeguarding WebSocket connections is paramount in today’s digital world.
By adhering to robust security practices such as input validation, encrypted connections, and thorough session management, organizations can mitigate these risks and harness the full potential of WebSockets securely. Remember, proactive measures today ensure seamless and secure communication tomorrow.
