{"id":17581,"date":"2021-10-28T12:45:58","date_gmt":"2021-10-28T07:15:58","guid":{"rendered":"https:\/\/www.varutra.com\/?p=17581"},"modified":"2022-12-02T11:48:27","modified_gmt":"2022-12-02T06:18:27","slug":"websocket-vulnerabilities","status":"publish","type":"post","link":"https:\/\/www.varutra.com\/varutravrt3\/websocket-vulnerabilities\/","title":{"rendered":"WebSocket Vulnerabilities"},"content":{"rendered":"


\nThis blog is about different types of WebSocket Vulnerabilities\/Findings. So, we will be discussing different types of flaws that may exist in WebSockets.<\/p>\n

WebSockets are becoming more and more popular these days because of the simplicity they provide for the communication between the client and the server.<\/p>\n

Firstly, let\u2019s get a brief overview of the WebSocket protocol<\/a>. The WebSocket protocol is an OSI application layer protocol that allows a client\u00a0and a web server to interact in full duplex (a communication channel where information can flow in both ways at the same time).<\/p>\n

 <\/p>\n

Different Vulnerabilities\/findings related to <\/strong>WebSockets<\/strong>:<\/h3>\n

While WebSockets are beneficial for generating full-duplex communication channels (in modern applications, the server may need to provide data to the client without the client making a special request, such as in instant messaging), they do not provide any further security benefits. As a result, we find the standard vulnerabilities of the HTTP protocol, as well as some unique ones.<\/p>\n

    \n
  1. DOS<\/strong>:<\/li>\n<\/ol>\n

    WebSockets allow an unlimited number of connections to the server to be established. This feature will allow to make a lot of connections which in turn will put a lot of demand on the server and use up all of its resources. The webpage then becomes noticeably slower. This way, a DOS attack can be launched against the server.<\/p>\n

      \n
    1. Cross-Site WebSocket Hijacking<\/strong>:<\/li>\n<\/ol>\n

      It is a type of CSRF<\/a> (Cross-Site Request Forgery) attack. When the server relies entirely on session authentication data (cookies) to complete an authenticated action, these types of attacks are feasible.<\/p>\n

      The attacker hides a request in a link on the screen of its (authenticated) victim in CSRF. The attacker tricks the victim into clicking on it to carry out the hidden request’s request. As a result, the attacker has the ability to make the victim do something harmful without the victim’s knowledge. The problem is that the attacker cannot view the server’s response to the request (due to the origin policy), which is no longer a concern with WebSockets because it doesn’t employ an origin policy. The attacker can now establish a full-duplex connection using the victim’s credentials.<\/p>\n

      When the WebSocket handshake is vulnerable to CSRF, the Cross-Site WebSocket Hijacking attack is feasible. Indeed, the origin of the original application determines the communication channel between the two parties (client\/server). As a result, if the protocol change request is entirely dependent on cookies, an attacker can lure a victim into starting a request with its session but based on the attacker\u2019s server.<\/p>\n

      Once trapped, the attacker can use WebSockets to communicate with the server without the victim’s knowledge. As with a traditional CSRF, the attacker can take actions in the recipient’s place while also reading server communications delivered over WebSockets.<\/p>\n

      It is better to put a unique token per session that cannot be guessed as a parameter of the handshake request to mitigate this vulnerability.<\/p>\n

        \n
      1. Sniffing Attacks:<\/strong><\/li>\n<\/ol>\n

        The WebSocket protocol transfers data in plain text, same as HTTP. As a result, man-in-the-middle attacks on this data are possible. Use the WebSocket Secure (wss:\/) protocol to avoid data leaks. WSS, like HTTPS, does not guarantee that your web application is secure, but it does assure that data is encrypted using Transport Layer Security (TLS).<\/p>\n

          \n
        1. Input-Validation Vulnerabilities:<\/strong><\/li>\n<\/ol>\n

          If the input validation on WebSocket user input is not proper, then Injection attacks targeting WebSocket vulnerabilities such as XSS, SQL injection, XXE, and others can be launched.<\/p>\n

            \n
          1. Unauthorized access to WebSocket communication<\/strong><\/li>\n<\/ol>\n

            It is possible to read and alter WebSocket communication at the network level if it is not established via the WebSocket over TLS (wss:\/) protocol. To do this, attackers need to be in a privileged position on the network.<\/p>\n

            WebSockets don’t have any kind of authentication or authorization. Since no authentication is necessary to create a WebSocket, attackers can create their own connections and potentially access data that is only accessible via HTTP authentication. Attackers can obtain unauthorized access to information by sending WebSocket messages if access permissions are not checked within the connection.<\/p>\n

             <\/p>\n

            These are some of the different vulnerabilities that were found in WebSockets.<\/p>\n

            Now, we will see the demo of one type of vulnerability i.e., Input-Validation Vulnerability. For demonstration purpose, let\u2019s navigate to a Portswigger lab to see the exploitation.<\/p>\n

            Lab<\/strong>:<\/p>\n

            Step 1:<\/strong> Access the lab and go to the live chat page.<\/p>\n

            \"Access<\/p>\n

            Step 2:<\/strong> In the live chat page, enter the message.<\/p>\n

            \"In<\/p>\n

            Step 3:<\/strong> Intercept the message request in Burp.<\/p>\n

            \"<\/p>\n

            Step 4:<\/strong> In the intercepted request, enter the payload in the WebSocket message.<\/p>\n

            \"In<\/p>\n

            Step 5:<\/strong> Forward the request and the payload will be executed and you will get a pop-up in your browser.<\/p>\n

            \"Forward<\/p>\n

            Thus, the lab is executed. Here, we have bypassed the client-side input validation in the chat and executed the payload.<\/p>\n

            \u00a0<\/strong><\/p>\n

            Mitigation\/Prevention of Websocket Vulnerabilities<\/strong>:<\/h3>\n

            Following some protective measures while using WebSockets will mitigate the above-mentioned vulnerabilities to some extent.<\/p>\n