Everything You Need to Know About Web Socket Pentesting

What is WebSockets?

WebSockets is a bi-directional, full-duplex communications protocol initiated over HTTP. They are commonly used in modern web applications for streaming data, Chat applications, and other asynchronous traffic. It is a protocol where the client and server can send the messages simultaneously over the channel.

Types of Tests

When it comes to WebSockets, we generally encounter the following security testing methodologies:

Black Box Testing:

We know how in black box testing, an entity is tested without much knowledge about its internal structure or design. Let’s find out how black box testing is conducted in the case of WebSockets.

1. Identify that the Tested Application uses WebSockets

This can be done by inspecting the client-side source code of the application for the presence of ws:// or wss:// URI (Uniform Resource Identifier) scheme. Developer tools of browsers like Google Chrome can also be used to view the Network and WebSocket communication. ZAP’s WebSocket tab could also be used for the same purpose.

Resources like websocket.org also offer ways to drive WebSocket tests. They let the users save a piece of code locally into their PCs and run that code in the browser to open a WebSocket connection and run the required test. One could also use the developer tools in the browser to process WebSocket requests directed to locally hosted APIs.

2. Verify the Origin Header Field

In the WebSocket standard, an origin header field is defined which is generally used to differentiate between the connections coming from different hosts and also the connections established between the browser and another network client. Origin headers are basically added by the user agents to elaborate the security contexts which led the user agent to start an HTTP request. These origin headers are later used by the HTTP servers to prevent and mitigate the Cross-Site Request Forgery (CSRF) vulnerabilities.

If the Origin header is not verified during the initial WebSocket handshake, the server may accept connections from any origin and this may result in serious security vulnerabilities. The origin header can be verified by using a WebSocket client to attempt to connect to the remote WebSocket server. In case a connection is established, this would mean that the origin header is not being verified in the WebSocket handshake.

3. Integrity and Confidentiality

In order to maintain the confidentiality and integrity of information during the entire process, it is essential to verify that the WebSocket connection uses SSL to transport sensitive wss:// information. It is also essential to check the SSL implementation for security issues.

4. Authentication/Authorization

WebSockets are not known to handle authorization/authentication and that is why normal black-box tests should be carried out for them. This means that if a WebSocket is opened via a page, it doesn’t receive any kind of authorization/authentication and you need to take some extra steps in order to secure the WebSocket connection. You can also use the same authentication measures you are using on your web views for your WebSocket connections too.

5. Input Sanitization

Injection attacks are as probable over WebSockets as they are over any other mechanism like the HTTP connections. Three of the top five website vulnerabilities namely Cross-site Scripting, SQL Injection and Remote File Inclusion can be attributed to input sanitization. Some of the common pathways which hackers use to alter user input data and infiltrate into WebSockets include GET requests, POST requests and cookies. That is why if the data is coming from an external client, input sanitization must be done before processing it.

Input sanitization essentially means the cleansing of the user input in order to prevent it from exploiting the security loopholes in the system. But, it’s important to understand that thorough sanitization of user input is not an easy task. And the best approach one can follow while handling this tough task is to focus on the context in which the user input will be utilized.

Simple measures like sanitizing data before output, enclosing attributes within quotes, and escaping user inputs before including them in SQL queries can go a long way and prevent attacks and exploits which might result because of poor input sanitization.

Grey-Box Testing

In the case of grey-box testing, the tester has only partial knowledge about the application structure. The only major difference from black-box testing is that the pen-tester may have the API documentation in this case which might include information related to WebSocket requests and responses.

What is the main difference between WebSocket and normal HTTP Communication?

HTTP is a half-duplex stateless protocol where the client sends a request to the server and then waits for the server’s response whereas, in the WebSockets, it is a full-duplex stateless protocol that is initiated over HTTP and is long-lived. It doesn’t wait for the server to respond back, instead, the client can send any number of requests to the server.

A full-duplex and persistent connection means that instead of the conventional request and response, the WebSocket connection stays active for as long as the application is in running state and allows simultaneous communication between the client and server because it is full-duplex.

WebSockets are preferred in the applications which require low latency communication. Although both HTTP and WebSockets have equal sized initial handshakes for connection, in case of WebSockets, the handshake is performed only once.

Efforts are being made to improve the latency and performance of HTTP protocols, but it is still likely that WebSockets will always have an edge in terms of latency when it comes to client to server data transfer.

How the WebSocket handshake is done and related security issues

WebSocket connections are normally created using client-side JavaScript like the following:

var ws = new WebSocket("wss://normal-website.com/chat");

To establish the connection, the browser and server perform a WebSocket handshake over HTTP. The browser issues a WebSocket handshake request like the following:



If the server accepts the connection, it returns a WebSocket handshake response like the following:

At this point, the network connection remains open and can be used to send WebSocket messages in either direction.

Issues and Observations :

● The Connection and Upgrade headers in the request and response indicate that this is a WebSocket handshake.
● The Sec-WebSocket-Version request header specifies the WebSocket protocol version that the client wishes to use. This is typically 13 and is not a vulnerable parameter.
● The Sec-WebSocket-Key request header contains a Base64-encoded random value, which should be randomly generated in each handshake request. This header is not the one which uniquely identifies a user or can be used for authorization purposes.
● The Sec-WebSocket-Accept response header contains a hash of the value submitted in the Sec-WebSocket-Key request header, concatenated with a specific string defined in the protocol specification. This is done to prevent misleading responses resulting from misconfigured servers or caching proxies.
● The wss protocol establishes a WebSocket over an encrypted TLS connection, while the ws protocol uses an unencrypted connection. So if the server is accepting connections from ws protocol it is vulnerable to MITM attacks.
● This protocol doesn’t prescribe any particular way that the servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.

WebSockets does not follow same-origin-policies.

How to Test the Security of WebSockets?

The number of tools which can test WebSocket implementations is not that large. However, the two best-known tools for the security testing of WebSockets are ZAP and Burp. With the help of these tools, you can intercept and improvise WebSocket frames with ease.

You can also use the Chrome development tools to keep a check on the WebSocket traffic. Once you identify the most suited tool for your purpose, the rest of the security audit part for WebSockets (access rights tests, injection tests, workflow tests) is nearly similar to that of general HTTP requests. If the protocol of the WebSocket is vulnerable to expansive attack surfaces, focusing on the configuration part can limit the risks manifold, as is the case for HTTP protocols.

In order for the identified security testing tool to work properly, it must have some crucial features present. Here is a list of some of those security testing functions:

1. Open a Connection to WebSocket Server

The tool must be able to open a WebSocket connection to the server. The server can either be used with non-encrypted (ws://) or encrypted (wss://) connection. The features of manipulating the Origin Header and support of user-provided subprotocols should also be there.

2. Close WebSocket Connection if Requested

If the user or the WebSocket server requests, the tool must be able to close the WebSocket connection as well.

3. Keep the Connection Alive And Send/Receive Messages

The tool should be able to send/receive user-provided and server-provided messages and also keep the connection alive. Message formats like UTF-8 and binary must be supported by the tool as well.

4. Log Data And Messages

The tool must be able to log data being sent to the log functions and also log all the WebSocket messages while the connection is in a live state. All the logs must be maintained on files as well.

5. User Input

The tool should support user input and be able to handle and process it as well.

6. Print Data

The WebSocket security tool should also be able to print essential data to any user interface for informational or documentation purposes.

7. Proxy Support

The security tool should also support the use of HTTP proxies.

How to Intercept and modify WebSocket messages?

You can use Burp Proxy to intercept and modify WebSocket messages, as follows:
● Configure your browser to use Burp Suite as its proxy server.
● Browse to the application function that uses WebSockets. You can determine that WebSockets are being used by using the application and looking for entries appearing in the WebSockets history tab within Burp Proxy.
● In the Intercept tab of Burp Proxy, ensure that interception is turned on.
● When a WebSocket message is sent from the browser or server, it will be displayed in the Intercept tab for you to view or modify. Press the Forward button to forward the message.
● The WebSockets messages can be seen in WebSocket history, where you can see all the requests and responses that have taken so far with the server.
● If you wish to replay any message you can simply just send the particular message from the history to the repeater.

Common Vulnerabilities associated with WebSockets

● Origin Verification → It is the server’s responsibility to verify the Origin header in the initial HTTP WebSocket handshake. If the server does not validate the origin header in the initial WebSocket handshake, the WebSocket server may accept connections from any origin. This could allow attackers to communicate with the WebSocket server cross-domain allowing for CSRF-like issues.
● Most Chat applications which are using WebSockets are vulnerable to XSS because the input sanitization is not implemented properly by the application and it trusts the user input.
● Misplaced trust in HTTP headers to perform security decisions, such as the X-Forwarded-For header.
● Flaws in session handling mechanisms, since the session context in which WebSocket messages are processed, is generally determined by the session context of the handshake message.
● Most applications are vulnerable to IDOR and authorization issues as there is no header in WebSocket which can check for such issues.
● WebSockets let an unlimited number of connections reach the server. This lets an attacker flood the server with a DOS attack. This greatly strains the server and exhausts the resources on that server. Then the website slows down greatly.
● The most widely found vulnerability in WebSocket is Cross-Site WebSocket Hijacking.

1. Cross-Site WebSocket Hijacking (CSWSH)

A Cross-Site WebSocket Hijacking attack is essentially a CSRF on a WebSocket handshake.

When a user is logged into victim.com in her browser and opens attacker.com in the same browser, attacker.com can try to establish a WebSocket connection to the server of victim.com.

Since the user’s browser would automatically send over her credentials with any HTTP/ HTTPS request to victim.com, the WebSocket handshake request initiated by attacker.com would contain the user’s legitimate credentials.

Related Topic- Understanding OWASP Top 10: Cross Site Scripting (XSS)

This means the resulting WebSocket connection (created by attacker.com) would have the same level of access as if it originated from vicitm.com .

After the WebSocket connection is established, attacker.com can communicate directly to victim.com as a legitimate user.

2. Structure of an attack

To carry out the attack, an attacker would create a script that will initiate the WebSocket connection to the victim server. She can then embed that script on a malicious page and trick a user into accessing the page.

When the victim accesses the malicious page, her browser will automatically include her cookies into the WebSocket handshake request (since it’s a regular HTTP request).

The malicious script crafted by the attacker will now have access to a WebSocket connection created using the victim’s credentials.

Impact of Cross-Site WebSocket Hijacking

Using a hijacked WebSocket connection, the attacker can now achieve a lot of things:

WebSocket CSRF: If the WebSocket communication is used to carry out sensitive, state-changing actions, attackers can use this connection to forge actions on behalf of the user. For example, attackers can post fake messages onto a user’s chat groups.

Private data retrieval: If the WebSocket communication can be used to retrieve sensitive information via a client request, attackers can initiate fake requests to retrieve sensitive data belonging to the user.

Private data leaks via server messages: Attackers can also simply listen in on server messages and passively collect information leaked from these messages. For example, an attacker can use the connection to eavesdrop on a user’s incoming notifications.

Key Takeaways

The key takeaways when it comes to WebSocket security are as follows:

1. Always thoroughly examine your WebSockets

When it comes to security, WebSockets are often ignored by security practitioners. It must be made a regular practice to examine WebSocket traffic and other security parameters using tools like ZAP and Burp Suite and even use developer tools from the browsers to do that. Preferably this should be done during the penetration testing phase.

2. WebSockets have nothing to do with cookies

Although a cookie may be returned on the same request that initiates a WebSocket, it doesn't mean that cookie has anything to do with the WebSocket protocol. Your browser's protocol changes to establish a WebSocket connection.

In this process, however, the server doesn't get any cookies to validate the established connection. Generally, if an application is using WebSockets, you must examine its traffic and determine if any substitute method of authentication or authorization is taking place. Chances are that you won't find any such instance.

3. WebSockets are not affected by the Same Origin Policy

WebSockets are not affected by the Same Origin Policy and the corollary CORS, i.e. Cross-Origin Resource Sharing. But why so? This is because WebSockets are an entirely different protocol from the HTTP.

Most of the security solutions make this assumption that the WebSockets will follow the same rules as the HTTP traffic, but this is not the situation. And this becomes very important to understand while testing them.

4. In case of WebSockets, prefer web application penetration testing over other methods

Most of the typical security scanners won't detect the serious authorization and authentication flaws that might exist in WebSockets. In order to detect such vulnerabilities, it is important to know where to look for what and thoroughly understand the context. That is why penetration testing techniques should be the go-to method in case of WebSockets.

Also, the previously explained methods of black and grey box testing of WebSockets will also ensure a thorough security analysis of all the involved mechanisms.

Pentesting tools for WebSocket

● OWASP Zed Attack Proxy
● Burp Suite
● Google Chrome Simple Web Socket Web client
● Cross-Site WebSocket Hijacking Tool

Related Topic- 12 Best Penetration Testing Tools for Security Assessment

Conclusion

The WebSocket landscape is continuously evolving and along with it are evolving the associated security vulnerabilities. One thing which needs to be understood is that every WebSocket isn’t a vulnerability. However, if a WebSocket vulnerability is encountered, it must be treated with high priority. Moreover, the organizations dealing with WebSockets must be extra cautious and understand the importance of implementing all the security controls in place when it comes to WebSockets.