Comprehensive (CSWSH)
In modern web applications, WebSockets are commonly used. They’re started with HTTP and offer long-lasting connections with asynchronous communication in both directions.
WebSockets are utilized for a variety of tasks, including user interaction and the transmission of sensitive data. Almost any web security flaw that may occur with normal HTTP can also occur with WebSockets connections.
RFC 6455 defines the WebSocket protocol. The protocol has two URI schemes:
ws: / host [: port] path [? query] for ordinary connections.
wss: / host [: port] path [? query] for TLS tunnel connections.
WebSockets are widely used in current web development, and they are supported by all major programming languages and browsers. Online chat rooms, message boards, web interfaces, and commercial applications all use it. You can easily find WebSocket applications on the Internet by using the search engine shodan.io. It is sufficient to formulate a simple query.
I was not a lazy slob and completed the following tasks:
Search for Sec-WebSocket-Version HTTP / 1.1 400 Bad Request returned 106,165 results on 20/08/2021
As a response, More than One Hundred Thousand address from all across the world was discovered.
ESTABLISHING A RELATIONSHIP Let’s have a look at WebSocket in action. A handshake is the first step in communication between a client and a server. The client and server use the HTTP protocol for the handshake, however, the format of the delivered messages differs slightly. Not all HTTP message criteria are met. For example, the Content-Length header is lacking.
First, the client establishes a connection with the server and sends the following request:
Connection: Sec-WebSocket-Version, Sec-WebSocket-Key Upgrade and Upgrade: WebSocket headers are necessary; else, the server will respond with HTTP / 1.1 400 Bad Request. The following is how the server responds to the client’s request:
The client generates the Sec-WebSocket-Key header as a random 16-byte value encoded in Base64. In Go, there is a version of the heading formation:
The following procedure is used to create the Sec-WebSocket-Accept header in the response. The GUID 258EAFA5-E914–47DA-95CA-C5AB0DC85B11 is concatenated with a string value from the Sec-WebSocket-Key header. The SHA-1 hash is then calculated using the string from the first paragraph. The hash is encoded in Base64. In Go, there is a version of the heading formation:
The Sec-WebSocket-Key and Sec-WebSocket-Accept headers aren’t used to authorize or support sessions; instead, they make sure that both the request and the response are using the WebSocket protocol. This ensures that the server does not accept requests from clients that do not use WebSockets.
RFC 6455 further recommends that the Sec-WebSocket-Key be chosen at random for each connection. This means that any cached proxy result will have an invalid Sec-WebSocket-Accept, causing the handshake to fail instead of reading the cached data accidentally. The client verifies the Sec-WebSocket-Accept value and expects the 101 Switching Protocols status code to finish the handshake. The initial HTTP connection is replaced with a WebSocket connection that uses the same TCP / IP connection after the handshake is completed. Either party can begin sending data at this moment.
It is convenient to utilize the “Developer Tools” provided, for example, in Chrome, to monitor WebSocket traffic.
TRANSFER OF DATA What is the method for sending messages to WebSocket?
Data is sent in a series of frames through the WebSocket protocol. The header of the frame comprises the following data:
whether the message is fragmented;
kind of transmitted data — all code;
whether the message was masked — mask flag;
data size;
mask key (32 bits);
other control data (ping, pong …).
The table illustrates the frame format.
To understand the Frame Format in-depth, Can refer to Base Framing Protocol
The client’s messages must all be disguised. An example of a “Hello world!” text message sent to a client (data from tcpdump):
Masking is done by the usual XOR with the mask key. The client must change the key for each frame transmitted. The server should not mask its messages. An example of sending a text message “Hello world!” server:
Because the disguising of transmitted messages is not cryptographic, the TLS protocol and the WSS scheme should be used with WebSocket to maintain confidentiality.
VULNERABILITY IN ACTION It’s time to move on to CSWSH now that the protocol has been figured out. When dealing with browsers, the WebSocket protocol employs an Origin-based security architecture. SOP (Same-origin policy) and other security procedures do not apply to WebSocket. According to RFC 6455, the server can check Origin or not when establishing a connection:
Note: The origin of the script that establishes the connection is indicated by the Origin header element in the client handshake. Origin is changed to lowercase and serialised to ASCII. This information MAY be used by the server when deciding whether or not to accept an incoming connection. If the server does not check the origin of connections, it will accept them from wherever. If the server refuses to accept the connection, it must return an HTTP error code (for example, 403 Forbidden) and terminate the WebSocket handshake described in this section.
The CSWSH flaw is caused by a lack of or incorrect validation of the Origin header in the client handshake. This is a WebSocket-specific version of the Cross-Site Request Forgery (CSRF) vulnerability. An attacker might fake the handshake request using a CSRF attack and manipulate messages delivered and received over the WebSocket connection if a WebSocket application uses cookies to govern user sessions.
The hacker’s page can then use the connection to send arbitrary messages to the server and view the content of the messages it receives back. This means that, unlike traditional CSRF, an attacker can communicate with a compromised application in both directions.
With a successful CSWSH attack, a hacker can:
Perform unauthorized actions while impersonating a victim user. An attacker can send arbitrary messages to the server application, just like with ordinary CSRF. An attacker can generate relevant cross-domain communications and commence these operations if it exploits client-generated WebSocket messages to accomplish sensitive actions.
Obtain confidential information that the user has access to. A cross-site WebSocket hijacking, unlike ordinary CSRF, allows an attacker to communicate with a susceptible application in both directions using a controlled WebSocket. An attacker could intercept such communications and the data of the victim user if the application uses server-generated WebSocket messages to return any sensitive data to the user.
TEST ENVIRONMENT FOR CSWSH Consider the CSWSH attack utilizing the vulnerable application………………wss: /echo.websocket.org as an example. The following is the offensive strategy.
Let’s go over the stages, and we’ll show you the messages in HTTP format that were received at each level.
The victim’s browser breaks down which is controlled by the attacker
The site sends users a page with malicious content:
The script is executed by the victim’s browser, which connects to the WebSocket application ws: /echo.websocket.org in the victim’s context, passing the cookie value:
The application starts a new WebSocketcookie-related connection with the header Origin: http://attackers-domain. SESSIONID=bigsecret:
On behalf of the victim, the attacker sends an attackers-message, The application that is in charge of the WebSocket sends a response message. Because our app is an echo server, the response will be an attackers-message as well.
At the end of the process, the server’s response is transmitted to the attacker-controlled domain:
PROTECTION FROM THE CSWSH You can defend yourself from CSWSH in two ways:
Use individual random tokens (e.g. CSRF tokens) in the handshake request and validate them against the server;
Check the Origin header of the WebSocket handshake request on the server.
Sometimes, but not usually, CSWSH protection is already integrated into the libraries. In the Gorilla WebSocket framework, CSWSH protection is implemented as follows:
The default setting for origin check is to compare the values of the Host and Origin headers from the handshake request.
Last updated